Gcc предпочитает статические библиотеки для общих объектов при связывании?

При связывании с библиотеками, использующими параметр -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, но это не принесло ожидаемых результатов

Ответы

gcc ... source.c ... /usr/lib32/libmysuperlib.a ...