В чем разница между в /lib/i386 в-линукс-дистрибутив GNU/библиотеки libc.так.6, в /lib/x86 и 64-ОС Linux-дистрибутив GNU/библиотеки libc.так.6 и /usr/lib в/x86 и 64-ОС Linux-дистрибутив GNU/библиотеки libc.так?

Я установил Matlab в моем Linux Mint 14 Nadia (uname-a показывает: Linux Ideapad-Z570 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux), и при вызове его из командной строки Я бы получил: "/lib64/libc.так не нашли".

я последовал за справкой по mathworks, сделав ссылку в /lib64 как:

ln -s /lib/x86_64-linux-gnu/libc.so.6 .

это решило проблему.

теперь, если я сделаю местоположение этой библиотеки, я получу:

locate "libc.so"
/lib/i386-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc.so

Я компиляция с gcc на этом компьютере, и я хотел бы иметь полные 64-битные компиляции. Что именно означает иметь все эти разные libc.так библиотеки? какой из них будет использовать компилятор gnu? нужно ли мне делать что-то другое с gcc для компиляции для 64 бит?

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

6
64bit gcc libc

3 ответов

в/lib/i386 в-линукс-дистрибутив GNU/библиотеки libc.так.6

это 32-разрядная версия библиотеки.

в/lib/x86_64 с-линукс-дистрибутив GNU/библиотеки libc.так.6

это 64-разрядная версия библиотеки.

оба обычно являются символическими ссылками на фактический файл библиотеки, который обычно будет называться в соответствии с номером выпуска glibc, например libc-2.15.so

в/usr/lib в/x86_64 с-линукс-дистрибутив GNU/библиотеки libc.так

это не библиотека, а файл сценария компоновщика, который ссылается на вышеуказанные символические ссылки.

зачем нам все это нужно:

во-первых, независимо от установленной версии libc, компоновщик всегда будет искать libc.so, потому что драйвер компилятора всегда будет передавать компоновщику -lc параметры. Имя libc остается неизменным и обозначает самую последнюю версию библиотеки.

в симлинки libc.so.6 названы в честь soname, равной библиотеки, которая более или менее соответствует версии библиотеки ABI. Исполняемые файлы, связанные с libc.so фактически содержат зависимости времени выполнения от libc.so.6.

если мы представим, что когда-нибудь выпущена несовместимая libc, это soname может быть названо libc.so.7, например, и эта версия coukld сосуществует со старым libc.so.6 версия, таким образом исполняемые файлы, связанные с одним или другим может сосуществуют в одной системе,

и, наконец, на имя libc-2.15.so относится к выпуску libc, при установке нового пакета libc имя изменится на libc-2.16.so. При условии, что он бинарно совместим с предыдущей версией,libc.so.6 ссылка останется с таким именем, и существующие исполняемые файлы будут продолжать работать.

11

чтобы найти, какой из них использовать, вы должны сначала найти того, что ld (компоновщик) использует для поиска библиотек, например:

ld --verbose | grep SEARCH

для меня это дало мне этот выход:

SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64"); SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");

Это означает, что на моем компьютере, ld смотрит в эти каталоги, по порядку:

  1. / usr/x86_64-неизвестно-linux-gnu / lib64
  2. / usr/x86_64-неизвестно-linux-gnu / lib
  3. / usr / lib
  4. / usr / local / lib

так если libc был в /usr/x86_64-unknown-linux-gnu /lib64, и libc также был в/usr /lib, он будет использовать версию/usr/x86_64-unknown-linux-gnu / lib64, потому что она была указана первой.

2

созданная вами символическая ссылка не будет иметь никакого влияния на GCC. 32-разрядная версия используется только при компиляции с помощью -m32 флаг GCC. GCC не будет пытаться генерировать 32-разрядные двоичные файлы, если вы специально не скажете ему (используя этот флаг.)

0