вязывании с библиотеками с использованием-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 всегда будет ссылаться на общий объект, а не на статическую библиотеку.

конечно, перемещая / удаляя / удаляя рассматриваемые общие объекты, и просто оставляя статические библиотеки, скажем,/usr/lib32, это обходной путь, но это не очень хороший

нота:

да, я прочитал о том, как связать общие объекты и библиотеки, и я не пытаюсь создать «полностью статически связанный общий объект»да я пробовал-Wl,-static -lfoo -Wl,-Bdynamic, но не принес ожидаемых результатовда я пробовал-l:libfoo.a также, но это не принесло ожидаемых результатов