как запретить линкеру версионирование символов?

собирай с -static, если размер не особо критичен, там относительно немного добавится, либо в chroot, либо http://www.trevorpounds.com/blog/?p=33

А, может, просто нужно взять дистрибутив, где libc аккуратно собрана? Например, в Debian testing (Wheezy) libc версии 2.13:

$ objdump -T /lib/x86_64-linux-gnu/libc-2.13.so
...
00000000000ce890  w   DF .text	000000000000005e  GLIBC_2.2.5 open
...
00000000000cea80  w   DF .text	000000000000005e  GLIBC_2.2.5 read
...
00000000000ceae0  w   DF .text	000000000000005e  GLIBC_2.2.5 write

#include <unistd.h>
#include <string.h>

int main()
{
        const char* str = "Hello\n";
        write(STDIN_FILENO, str, strlen(str));
        return 0;
}

$ gcc -Wall -g -o test test.c
$ objdump -T test

test:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 write
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 strlen
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__

А, может, просто нужно взять дистрибутив, где libc аккуратно собрана? Например, в Debian testing (Wheezy) libc версии 2.13:

феерическая чушь, версия символа апается при смене поведения реализации, в остальных дистрибутивах все тоже самое

Так моё словесное описание, значит, чушь, а что насчёт вывода objdump?

Мне кажется, вы не совсем понимаете, как это работает.

http://people.redhat.com/drepper/dsohowto.pdf

http://stackoverflow.com/questions/8823267/linking-against-older-symbol-versi...

А то, что вы хотите, надо делать с двух сторон: 1/ runtime linker 2/ link editor. Вы о котором, кстати?

В Солярисе есть опция LD_NOVERSION для *runtime* linker.

А ежели действительно open(), read(), write(). То можно вообще избежать libc.

Так моё словесное описание, значит, чушь, а что насчёт вывода objdump?

а ты подумай, если не догадаешься скомпилируй это:

#include <setjmp.h>
#include <stdio.h>

main() {
	mkstemps();
	jmp_buf buf;
	if(setjmp(buf)==1111) printf("!!\n");
	longjmp(buf,rand());
}

с -O2

можешь заодно собрать свой и мой пример на любом другом дистрибутиве

$ man mkstemps
...
VERSIONS
       mkostemp() is available since glibc 2.7.  mkstemps() and mkostemps() are available since glibc 2.11.
...

Действительно, чуда не произошло, и mkstemps, которая появилась в 2.11 недоступна в какой-нибудь старой версии 2.2.5:

$ objdump -T test

test:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.11  mkstemps
...

Вот если взять пример memcpy, то да можно попасть из-за несовместимого изменения в реализации (а не просто изменения, оптимизации). Но тогда можно попробовать вышеуказанный линк на stackoverflow. Но дебиан по-прежнему поддерживает версию даже для memcpy:

$ objdump -T /lib/x86_64-linux-gnu/libc-2.13.so  | grep memcpy
...
0000000000089220 g   iD  .text	000000000000003c  GLIBC_2.2.5 memcpy
...

Вторая ссылка интересна

Но дебиан по-прежнему поддерживает версию даже для memcpy:

еще одна чушь, версия memcpy апнулась только в 2.14

P.S. Эх, то, на что отвечаю, меняется просто на глазах :) Ну, это ответ на первую версию поста.

здорово, а что на вторую не отвечаешь?

и не забудь проверить на любом другом дистрибутиве

Но дебиан по-прежнему поддерживает версию даже для memcpy:

еще одна чушь, версия memcpy апнулась только в 2.14

И чего это у людей кое-что с выходом 2.13 стало не так работать как раньше?

здорово, а что на вторую не отвечаешь?

Ну, когда у меня будет под рукой настолько новый дистрибутив, чтобы было свежее 2.13... Даже не знаю, когда это может произойти.

И чего это у людей кое-что с выходом 2.13 стало не так работать как раньше?

возможно дебианопроблемы с их любовью к патчам, как я уже говорил символ апнули в 2.14

Попробовал согласно ссылке анонимуса срезать завязки на новые glibc. уперся в то что stdio для своих буфферов напрямую дергает mmap() вместо malloc() и это зацепляет код который нельзя выдергнуть из статической libc.

патч для фикса есть http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html но при этом естественно подразумевается пересборка статической версии glibc.

вобщем я в размышлениях

Собирай статически с dietlibc.

Хм. полностью статически? не думаю что это хорошая идея

А в чём минусы, кроме пресловутых общесистемных исправлений безопасности?

Собери в старой системе.

ну например статические бинарники могут дергать сисколы только через шлюз int 80h, что ресурсозатратно.

щас wota начнет снова спорить что так делать нельзя, но я все же посоветую использовать apgcc.

использование проще некуда — «CC=apgcc make».

автоматически определяет минимально возможную версию glibc ABI, и линкуется к ней. попутно вырезает ненужные зависимости, которые прилетают из-за кривости pkg-config (или кривости чего-то еще, тут не уверен). например когда линкуешься к gtk2, автоматом добавляется libpng, вот apgcc это вырезает — зависимости от libpng не будет.

правда, я не знаю, откуда его щас можно скачать, т.к. проект autopackage, в рамках которого появилась эта утила, слился с другим, сайт закрылся, и что там дальше случилось непонятно, но у меня есть, могу поделиться.

Спасибо, это интересная штука. ссылку я нашел в гугле http://web.mit.edu/andersk/arch/share/bin/apgcc

Вмержили его в этот проэкт https://launchpad.net/listaller попутно переименовав в ligcc (http://listaller.tenstral.net/wiki/doku.php/ligcc)

о, спасибо за инфу, буду знать.