'gcc -lXext' завершается успешно, но libXext не связан

Бинарный файл был связан с gcc с помощью:

gcc notion.o -Wl,-whole-archive ../ioncore/ioncore.a -Wl,-no-whole-archive -L/usr/X11R6/lib -lX11 -lXext -lSM -lICE -Wl,-whole-archive -L../libmainloop -lmainloop -lextl -ltu -Wl,-no-whole-archive pkg-config --libs lua5.1 -ldl -lm -lrt -Xlinker --export-dynamic -o понятие

Связывание выполнено успешно, однако при запуске приложения пользователь сообщает о сбое из-за неопределенного символа (XShapeCombineRectangles). XShapeCombineRectangles должен быть доступен в libXext.

Действительно, проверка с помощью ldd, Xext не указана как зависимость разделяемой библиотеки для этого пользователя:

linux-gate.so.1 => (0x0068f000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x00ec7000)
liblua5.1.so.0 => /usr/lib/i386-linux-gnu/liblua5.1.so.0
(0x00226000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x005da000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005e1000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x0032c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00335000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x007d6000)
/lib/ld-linux.so.2 (0x00882000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0
(0x006dc000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x00110000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6
(0x00dd8000)

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

Что здесь может происходить?

(Дополнительный контекст: об этой ошибке было сообщено на http://sourceforge.net/tracker/?func=detail&aid=3427206&group_id=314802&atid=1324528)


gcc linux crash linker dynamic-linking
person Arnout Engelen    schedule 22.10.2011    source источник
comment
Вы уверены, что связываете не статическую библиотеку libXext, а не общую библиотеку?   -  person nos    schedule 23.10.2011
comment
Я не совсем уверен, но запуск с -Wl,-y,XShapeCombineRectangles показывает /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libXext.so, поэтому я бы сказал, что это динамическое связывание, верно?   -  person Arnout Engelen    schedule 23.10.2011

Ответы (1)


arrow_upward
2
arrow_downward

Вероятно, ваш компоновщик (или gcc) автоматически добавляет --as-needed за кулисами, а в вашей системе XShapeCombineRectangles берется из какой-то библиотеки другой, чем libXext.

Вы можете узнать, какая библиотека определяет символ XShapeCombineRectangles в вашей ссылке: просто добавьте -Wl,-y,XShapeCombineRectangles в строку ссылки.

Добавление -v покажет, задействованы ли какие-либо --as-needed аргументы.

Вы можете заставить последний исполняемый файл ссылаться на libXext, добавив -Wl,--no-as-needed,-lXext в строку ссылки.

Обновление: я неправильно понял вопрос (а вы его очень плохо сформулировали).

Чтобы повторить:

  1. приложение связывается и правильно работает в системе OP, а ldd
    app     показывает зависимость от libXext
  2. приложение также подключается и запускается правильно в системе конечного пользователя, но ldd app не показывает libXext
  3. когда приложение пытается dlopen("de.so", ...) в системе конечного пользователя, это не удается с de.so: undefined symbol XShapeCombineRectangles

Если приведенные выше пункты верны, вполне вероятно, что

  1. Система конечного пользователя имеет libXext.a, но не libXext.so
  2. Главное приложение не вызывает XShapeCombineRectangles, только код в de.so выполняет
  3. Когда de.so связан, в его строке ссылки отсутствует -lXext.

Либо установка libXext.so, либо связывание основного приложения с -u XShapeCombineRectangles, скорее всего, решит проблему.

Чтобы понять проблему, вы можете прочитать это.

Я предполагаю, что на XShapeCombineRectangles не ссылаются из основного исполняемого файла, поэтому он не извлекается из libXext.a "книжной полки", следовательно, не экспортируется из основного исполняемого файла, несмотря на --export-dynamic.

person Employed Russian    schedule 22.10.2011
comment
Хм, nm /usr/lib/i386-linux-gnu/libXext.a | grep XShapeCombineRectangles действительно появился XShapeCombineRectangles в libXext - но я передам это, спасибо! - person Arnout Engelen; 23.10.2011
comment
поскольку он говорит, что в его системе указан libXext , я подозреваю, что в его системе основное приложение по какой-то причине зависит от функции libXext и поэтому при необходимости ссылается на нее. Для системы других пользователей основной исполняемый файл, возможно, не зависит от libXext, поэтому не ссылается на него (таким образом, --no-as-required может потребоваться, как вы говорите). Возможно, падение в приложении поврежденного файла .so (в котором libXext не указано как DT_NEEDED) вызывает сбой? - person Johannes Schaub - litb; 23.10.2011
comment
Ваша повторная формулировка проблемы верна, спасибо. 1) запуск с -Wl,-y,XShapeCombineRectangles заканчивается на /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libXext.so: definition of XShapeCombineRectangles, поэтому, похоже, это не так. 2) Это действительно так (ну, de.so и mod_dock.so). 3) Это действительно так (de.so построен gcc -shared -lrt init.o draw.o font.o colour.o brush.o fontset.o style.o precompose.o exports.o -o de.so). - person Arnout Engelen; 23.10.2011
comment
Действительно, когда я явно добавляю --as-as-необходимые к флагам компоновщика, я могу воспроизвести проблему - так что в моем случае основная программа также не использует libXext напрямую. Лучше всего было бы явно добавить --as-required, а также добавить -lXext при компоновке модулей, которые могут этого требовать, не так ли? - person Arnout Engelen; 23.10.2011
comment
@Arnout вам не нужны --as-необходимые или --no-as-необходимые, если вы правильно добавляете -Xext при связывании загружаемых модулей с помощью dlopen. Параметр --no-as-required - это просто обходной путь, если по какой-либо причине вы не можете правильно связать модули. - person Johannes Schaub - litb; 23.10.2011
comment
На самом деле мне не нужен --as-needed как таковой, но это все же улучшение, верно? 2 причины: 1) он может потерять неиспользуемые библиотеки 2) это делает сборку более предсказуемой (больше не --as-needed-поведение на некоторых машинах, а не на других) - person Arnout Engelen; 23.10.2011