Почему / usr / lib64 не находится по умолчанию в ld.so? - PullRequest
1 голос
/ 14 апреля 2020

Вчера я попытался обновить g cc с версии 8.4.0 до 9.3.0 путем сборки из исходного кода, поскольку последняя версия, которую можно установить через apt-репо Ubuntu, - 8.4.0.

Все процессы сборки и установки в порядке, и я могу скомпилировать любой код на С ++, даже с учетом функций, которые реализованы только с помощью g cc -9.3.0. Но я НЕ могу запускать свои программы, если я использовал в своем коде c ++ STL.

С помощью "ldd my-program" я обнаружил проблему. Похоже, что g cc -9.3.0 установил файл libstdc ++. So.6.0.28 в / usr / lib64 / , в то время как один ( libstdc ++. so.6.0.25 ) официальной версии (g cc -8.4.0) находится в / usr / lib / x86_64- linux -gnu / , поэтому ld.so может НЕ загружайте библиотеки для моей программы. Если я добавлю "/ usr / lib64" в LD_LIBRARY_PATH env var, это сработает.

Странно, что / usr / lib64 НЕ является одним из мест поиска по умолчанию в ld.so Kubuntu-18.04.4LTS, или я не прав?

Я знаю, что это можно решить с помощью LD_LIBRARY_PATH или добавить путь в /etc/ld.so.conf, мне просто интересно, что / usr / lib64 НЕ путь по умолчанию.

Кроме того, я рассмотрел процесс сборки:

Для того, чтобы максимально приблизить цели к официальным целям, полученным из репозитория apt Ubuntu, перед настройкой я использовал «echo | gcc -v -x c -E -», чтобы получить все параметры сборки из официальных целей g cc -8.4.0, а затем применить их к себе, как показано ниже:

~/projects/gcc-9.3.0/configure \
--build=x86_64-linux-gnu \
--disable-libgcj \
--disable-libstdcxx-debug \
--disable-libunwind-exceptions \
--disable-multilib \
--disable-vtable-verify \
--enable-__cxa_atexit \
--enable-bootstrap \
--enable-checking=release \
--enable-clocale=gnu \
--enable-default-pie \
--enable-gnu-indirect-function \
--enable-gnu-unique-object \
--enable-initfini-array \
--enable-languages=c,c++ \
--enable-libmpx \
--enable-libstdcxx-time=yes \
--enable-linker-build-id \
--enable-nls \
--enable-offload-targets=nvptx-none \
--enable-plugin \
--enable-shared \
--enable-threads=posix \
--host=x86_64-linux-gnu \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--prefix=/usr \
--program-suffix=-9.3 \
--target=x86_64-linux-gnu \
--with-abi=m64 \
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs \
--with-default-libstdcxx-abi=new \
--with-linker-hash-style=gnu \
--with-pkgversion='Ubuntu 9.3.0-6ubuntu1~18.04.4' \
--with-system-zlib \
--with-target-system-zlib \
--with-tune=generic \
--without-cuda-driver \
--without-included-gettext

Пожалуйста, отметьте опцию «--libdir = / usr / lib» явно устанавливает путь, по которому должны быть установлены целевые библиотеки. Но файл libstdc ++. so.6.0.28 все же был установлен в / usr / lib64 окончательно.

Какие вещи я пропустил?

Любая помощь или намек будут восприняты iated!

1 Ответ

1 голос
/ 14 апреля 2020

Не все исправления многоархива Debian / Ubuntu были интегрированы в основной набор инструментов GNU. Если вы хотите создать цепочку инструментов, совместимую с остальной частью системы, вам придется применять их вручную. См. debian/patches/gcc-multiarch.diff и debian/patches/gcc-multilib-multiarch.diff в пакете с исходным кодом gcc-9.

Использование /usr/lib вместо /usr/lib64 в загрузчике dynamici c, в дополнение к многоархатным путям, идет вернуться к предварительно многоархивным портам Debian (например, Debian 6.0 squeeze) и к исходному порту amd64. По этому вопросу есть очень старый отчет об ошибке и список рассылки:

Похоже, что это не могло быть исправлено в предстоящем выпуске Debian в то время, а потом зависло. (Извините, я не помню деталей.)

...