Внесены ли изменения в gcc 4.5 в отношении ссылок?

Question

У меня есть проект, который создает общую библиотеку, которая связана с другой, также общей, библиотекой.

Когда я компилирую и связываю его с помощью gcc 4.4, все работает:

1. нет предупреждения или ошибки времени компиляции,
2. нет предупреждения или ошибки времени компоновки и
3. ldd libmyproject.so правильно сообщает о зависимости с другой общей библиотекой.

С другой стороны, когда я компилирую и связываю его с gcc 4.5 (с точно такими же флагами), у меня появляются следующие симптомы:

1. нет предупреждения или ошибки во время компиляции,
2. нет предупреждения о времени или ошибке связывания , но
3. библиотека некорректно связана с другой разделяемой библиотекой: это проявляется, когда я запускаю ldd и не вижу соединения, итакже, когда я пытаюсь использовать его: хотя он работает с gcc 4.4, он аварийно завершает работу во время выполнения с gcc 4.5 с ошибкой «символ не найден» (конечно, из другой библиотеки).

Я посмотрел заметки о выпуске и мой intДело в том, что это как-то связано с новой оптимизацией времени соединения, но я не мог понять их достаточно подробно.

Кто-нибудь сталкивался с подобной ситуацией и / или есть какие-либо советы, чтобы предложить?

(Обратите внимание, что результаты с 4.6 похожи на 4.5).

Answer 1

Чтобы подвести итог ответа Мата из GCC 4.5 против 4.4 связывание с зависимостями и обсуждение в комментариях, вам нужно связать с:

--copy-dt-needed-entries and --no-as-needed

Answer 2

Вы можете отлаживать динамически связанное приложение с помощью переменной среды LD_DEBUG.Это опция ld-linux.so.2;ldd - это скрипт для установки такой опции.Все параметры описаны на странице http://linux.die.net/man/8/ld-linux man.

Как использовать LD_DEBUG (в bash; самый простой способ):

 $ LD_DEBUG=all ./your_program

Это включит отладку ld-linux.so.2 - динамический компоновщик времени выполнения.Он выведет много отладочной информации на stdout или stderr, и вы сможете

• 1) сравнить вывод "LD_DEBUG=all ./your_program_4.4" и "LD_DEBUG=all ./your_program_4.5"
• 2)посмотрите последние символы, которые нужно разрешить, и найдите ошибочный символ.

Кроме того, вы должны предоставить нам больше информации:

• 0) Какова ваша ОС и тип процессора?(покажите нам вывод uname -a) Какая версия libc?(запустите в bash for a in /lib*/libc.so.*;do echo $a; $a; done)
• 1) Что такое флаги компиляции самой вашей библиотеки?
• 2) Что является точной ошибкой при попытке запустить приложение?
• 3) Последние строки из вывода LD_DEBUG могут содержать ценную информацию

ОБНОВЛЕНИЕ: Хороший и точный ответ здесь: GCC 4.5 против 4.4 связывание с зависимостями (по Mat)

Answer 3

Убедитесь, что вы указали общие библиотеки после файлов вашего объекта (или источника) в командной строке компоновщика.

Именно так вам приходилось делать это со статическими библиотеками в прежние времена. Похоже, снова выгодно с последними версиями GCC. Насколько я могу судить, если он сканирует разделяемую библиотеку, которая не предоставляет никаких полезных символов, он игнорирует всю библиотеку, которая оптимизирует количество разделяемых библиотек, загружаемых во время выполнения, но требует, чтобы параметры -libname появлялись после объектных файлов.