При связывании с библиотеками, использующими параметр -l
(скажем, -lfoo
), gcc предпочтет общий объект для статической библиотеки, если они будут найдены (предпочтительнее libfoo.so
- libfoo.a
). Есть ли способ сделать gcc предпочтительнее статической библиотеки, если они найдены?
Проблема, которую я пытаюсь решить, заключается в следующем: я создаю плагин для приложения (имитатор полета под названием X-Plane) со следующими ограничениями:
- плагин должен быть в виде 32-битного общего объекта, даже при работе в 64-битной системе
- работающая среда не обеспечивает удобный способ загрузки общих объектов, которые не находятся в "нормальных" местоположениях, например
/usr/lib
или/usr/lib32
:- нельзя ожидать, что пользователь установит
LD_PRELOAD
илиLD_LIBRARY_PATH
для поиска общих объектов, поставляемых с моим плагином - работающая среда X-Plane не добавит мой каталог плагинов в `` LD_LIBRARY_PATH, прежде чем динамически загружать общий объект плагина, что позволит мне отправлять все мои обязательные общие объекты вместе с моим общим объектом плагина
- нельзя ожидать, что пользователь установит
- нельзя ожидать, что 64-разрядные пользователи установят 32-битные общие объекты, которые нетривиальны (скажем, не включены в пакет ia32-libs на ubuntu)
для решения вышеуказанных ограничений, возможным решением является связывание сгенерированного общего объекта с статическими 32-разрядными версиями всех нетривиальных библиотек. но при установке таких библиотек обычно устанавливаются как статические, так и динамические версии, и, следовательно, gcc всегда будет ссылаться на общий объект вместо статической библиотеки.
конечно, перемещение/удаление/удаление общих объектов, о которых идет речь, и просто оставление статических библиотек в say /usr/lib32
, это обход, но это не приятный
Примечание:
- да, я читал о том, как связывать общие объекты и библиотеки, и я не пытаюсь создать "полностью статически связанный общий объект"
- да, я пробовал
-Wl,-static -lfoo -Wl,-Bdynamic,
, но не приносил ожидаемых результатов - да, я тоже пробовал
-l:libfoo.a
, но это не принесло ожидаемых результатов