Мезон: попытка статически связать предварительно созданный .a с созданным мезоном .so приводит к бесчисленным ошибкам ко ⇐ C++

[Anonymous]

TL;DR: попытка статически связать предварительно созданную библиотеку сторонней библиотеки с моей собственной общей_библиотекой, связанной с dyn, вызывает лавину неопределенных ссылок code> ошибки из ld.
Статическая сторонняя библиотека dep:
была построена вне Meson с помощью CMake (с -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON). Эта библиотека встраивает большую часть своих собственных сторонних зависимостей непосредственно в свой репозиторий (как «вставленные исходные коды», если хотите — например, Lua, Jolt и другие) — и, таким образом, также в свои конечные 184 МБ. Вывод сборки libWickedEngine_Linux.a (известный благодаря созданному CMake compile_commands.json, а также потому, что нет такие проблемы, как описано ниже, когда он статически связан непосредственно с исполняемым файлом() вместо приведенного ниже .so).
Сказал libWickedEngine_Linux.a существует в моем meson.build, например:

Код: Выделить всё

dep_wicked = meson.get_compiler('cpp').find_library(
'WickedEngine_Linux',
dirs: [meson.project_source_root() / '.wi/build/WickedEngine'],
header_include_directories: include_directories('.wi/WickedEngine'),
required: true,
static: true,
)

Моя общая библиотека:
предполагается, что она статически связана с окончательным результатом сборки.so полностью соответствует приведенному выше .a< /код>. Он #include "entry-point .h" из-above-3rd-party-lib в свой собственный единственный файл .cpp, предназначенный для простого helloworlding, и выглядит следующим образом:

Код: Выделить всё

lib_cwicked = shared_library(
'cwicked',
dependencies: [dep_wicked, dep_sdl2],
include_directories: include_directories('.wi/WickedEngine'),
sources: ['src/cWicked.cpp'],
)

Проблема:
Теперь, когда я компилирую мезон в моем meson.build (что на самом деле просто две приведенные выше части в кавычках с префиксом project('cWicked', ['cpp']) и dep_sdl2 = dependency('SDL2', include_type: 'system', static: false)), сразу после печать связывая целевой шаг libcwicked.so, существуют все виды неопределенных ссылок на ошибки '' по ld, 100 или 1000, но в любом случае происходит заливка терминала. Небольшая выдержка:

Код: Выделить всё

/usr/bin/ld: /home/_/c/c/cWicked/.wi/WickedEngine/wiLuna.h:124:(.text.unlikely+0x3a2): undefined reference to `lua_pushnumber'
/usr/bin/ld: /home/_/c/c/cWicked/.wi/WickedEngine/wiLuna.h:125:(.text.unlikely+0x3ad): undefined reference to `lua_settable'
/usr/bin/ld: /home/_/c/c/cWicked/.wi/build/WickedEngine/libWickedEngine_Linux.a(wiLoadingScreen_BindLua.cpp.o): in function `Luna::gc_obj(lua_State*)':
/home/_/c/c/cWicked/.wi/WickedEngine/wiLuna.h:283:(.text._ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE6gc_objEP9lua_State[_ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE6gc_objEP9lua_State]+0x19): undefined reference to `lua_touserdata'
/usr/bin/ld: /home/_/c/c/cWicked/.wi/build/WickedEngine/libWickedEngine_Linux.a(wiLoadingScreen_BindLua.cpp.o): in function `Luna::constructor(lua_State*)':
/home/_/c/c/cWicked/.wi/WickedEngine/wiLuna.h:145:(.text._ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE11constructorEP9lua_State[_ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE11constructorEP9lua_State]+0x103): undefined reference to `lua_newuserdata'
/usr/bin/ld: /home/_/c/c/cWicked/.wi/WickedEngine/wiLuna.h:148:(.text._ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE11constructorEP9lua_State[_ZN4LunaIN2wi3lua21LoadingScreen_BindLuaEE11constructorEP9lua_State]+0x11a): undefined reference to `lua_getfield'

Но это касается не только Lua, можно сказать, что прокрутка вверх в терминале: то же самое можно сказать и о многих других сторонних библиотеках. > встроенный сторонний код.
Цель состоит в том, чтобы сторонний .a полностью находился внутри моего .so, а позже мои программы включали только и свяжите последнее. (Фактическая цель состоит в том, чтобы сделать последнюю библиотеку-оболочку C API, подключаемую через dyn, поверх этой статической сторонней библиотеки C++, подключаемой по дизайну, а не через dyn.)
Я' Я все еще немного новичок в Meson и создании многобиблиотечных проектов C/C++, поэтому, думаю, я ожидал, что все символы, существующие внутри .a, будут как бы вставлены в .so с помощью процесс называется «статическим связыванием» — при этом .so (или DLL) является таким же конечным типом артефакта сборки, как и любой исполняемый файл. Это «в принципе не так», или мой meson.build нуждается в дальнейших настройках?

Подробнее здесь: https://stackoverflow.com/questions/793 ... t-so-yield