Почему / usr / lib64 не находится в местоположении ld.so по умолчанию?

Вчера я попытался обновить свой gcc с версии 8.4.0 до 9.3.0 путем сборки из исходных кодов, потому что последняя версия, которая может быть установлена ​​через репозиторий Ubuntu, — это 8.4.0.

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

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

Странно, что / 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 -«, чтобы получить все параметры сборки официальных целей gcc-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:/https://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.

См. также:  Доступ запрещен при выполнении файла PUT с использованием предварительно подписанного URL-адреса S3

Что я пропустил?

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

Понравилась статья? Поделиться с друзьями:
IT Шеф
Комментарии: 1
  1. Leon

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

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

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

Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: