Tricky linking problem, is my meson.build wrong? (trying to link 3rd-party static lib into my shared lib)

[metaleap]

TL;DR: trying to statically link a pre-built 3rd-party lib dep into my own dyn-linked shared_library triggers an avalanche of undefined reference errors from ld.

The static 3rd-party lib dep:

was built outside of Meson with CMake (with -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON). That lib embeds most of its own 3rd-party deps directly inside its repo (as "pasted-in sources" if you will — eg. Lua & Jolt & more) — and thus also within it's final 184MB libWickedEngine_Linux.a build output (known because of its CMake-generated compile_commands.json, and also because there's no such problems as described below when it's statically linked directly into an executable() instead of the below .so).

Said libWickedEngine_Linux.a exists in my meson.build suchly:

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,
)

The shared lib of mine:

is supposed to statically link into its final build output .so fully the above .a. It #includes the-above-3rd-party-lib's "entry-point .h" in its own just-helloworlding sole .cpp file and looks like so:

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

The problem:

Now, when doing a meson compile on my meson.build (which is really just the above 2 quoted parts prefixed by project('cWicked', ['cpp']) and dep_sdl2 = dependency('SDL2', include_type: 'system', static: false)), just after printing the linking target libcwicked.so step, there are all kinds of undefined reference to '<someSymbolNameHere>' errors by ld, 100s or 1000s but anyway flood-filling the terminal. A mini extract:

/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<wi::lua::LoadingScreen_BindLua>::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<wi::lua::LoadingScreen_BindLua>::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'

But this isn't just about Lua, one can tell scrolling up in the terminal: also in the very same manner about many of the 3rd-party lib's other embedded 3rd-party code.

The goal here is that the 3rd-party .a lands fully inside my .so, and later my programs only include and link the latter. (Actual goal is to make the latter a dyn-linkable C API wrapper lib over that static 3rd-party by-design-not-dyn-linkable C++ lib, really.)

I'm still a bit new to Meson and building multi-lib C/C++ projects, so I guess I was expecting all symbols existing inside the .a to be kinda-sorta-pasted into the .so by the process called "static linking" — with an .so (or DLL) being just as much a final build artifact type as any executable is. Is that "principally not the case", or does my meson.build need further tweaks here?

[metaleap]

Solved, did need to add various find_library calls and add them to dependencies..