В чем разница между /lib/i386-linux-gnu/libc.so.6, /lib/x86_64-linux-gnu/libc.so.6 и /usr/lib/x86_64-linux-gnu/libc.so?

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

Я следил за справкой по математике, сделав ссылку в /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.so? какой из них будет использовать компилятор gnu? мне нужно сделать что-то другое с gcc для компиляции для 64 бит?

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


person Alejandro    schedule 09.12.2012    source источник
comment
пользователь 1889975, привет. Вы уверены, что все 3 libc.so разные? Затем выполните ls -l, чтобы найти символические ссылки. Кроме того, недавно был изменен путь по умолчанию к 32/64-битным библиотекам в смешанных 32/64-битных системах (с /lib64 на /lib/tr-ip-le/), дополнительную информацию см. на этой странице wiki.debian.org/Multiarch/TheCaseForMultiarch   -  person osgx    schedule 09.12.2012
comment
Я проверил, и это НЕ символические ссылки. Спасибо за предложение   -  person Alejandro    schedule 10.12.2012


Ответы (3)


/lib/i386-linux-gnu/libc.so.6

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

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

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

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

/usr/lib/x86_64-linux-gnu/libc.so

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

Зачем нам все это:

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

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

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

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

person chill    schedule 09.12.2012
comment
Большое спасибо. Это очень помогло мне понять, почему. - person Alejandro; 12.12.2012
comment
Почему они также называют скрипт компоновщика с помощью .so? Это сбивает с толку. - person Ciro Santilli 新疆再教育营六四事件ۍ 08.06.2015

Чтобы определить, какой из них использовать, вы должны сначала найти порядок, который 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/библиотека
  4. /USR/локальные/библиотека

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

person MiJyn    schedule 09.12.2012
comment
Очень интересно и полезно. Спасибо. В моем случае он сначала перечисляет /lib/x86_64-linux-gnu, поэтому я могу скомпилировать 64-битный код. Теперь я хочу понять это полностью. Почему тогда мой дистрибутив Linux установил эту библиотеку в нескольких разных местах? - person Alejandro; 09.12.2012
comment
@Алехандро, нет проблем! Если проблема решена, не могли бы вы отметить ее как таковую? - person MiJyn; 09.12.2012
comment
Извините, но я все еще хочу знать, почему так много мест? эти файлы копируются снова и снова? может быть причина в этом я думаю. Я отмечу это как решенное, когда получу эти ответы. Еще раз спасибо! - person Alejandro; 10.12.2012
comment
Да, есть. Из того, что я вижу, первый результат locate ... (/lib/i386...) - это 32-разрядная версия libc (необходима для запуска 32-разрядных приложений), вторая запись (/lib/x86_64...) - это 64-битная версия libc, а третья запись является символической ссылкой на вторую. Я не совсем уверен, почему создается символическая ссылка, но я думаю, что это как-то связано с совместимостью с другими программами или компиляторами. - person MiJyn; 10.12.2012
comment
На самом деле третий НЕ является символической ссылкой. Но я вижу, что ты говоришь - person Alejandro; 10.12.2012
comment
Ой, извините, я перечитал ваш пост. Второй является символической ссылкой, и он должен указывать на третий (если это не так, у вас могут возникнуть проблемы) - person MiJyn; 10.12.2012

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

person Nikos C.    schedule 09.12.2012
comment
Спасибо, очень ясно за точку зрения относительно того, будет ли gcc компилировать 64-битный код по умолчанию. - person Alejandro; 10.12.2012