Meson: Der Versuch, eine vorgefertigte „.a“ ​​statisch mit einer von einem Meson erstellten „.so“ zu verknüpfen, führt z ⇐ C++

[Guest]

TL; DR:Fehler von ld.
Die statische Drittanbieter-Bibliothek dep:
wurde außerhalb von Meson mit erstellt CMake (mit -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON). Diese Bibliothek bettet die meisten ihrer eigenen Drittanbieter-Deps direkt in ihr Repo ein (als „eingefügte Quellen“, wenn Sie so wollen – z. B. Lua & Jolt und mehr) – und somit auch innerhalb ihrer endgültigen 184 MB libWickedEngine_Linux.a-Build-Ausgabe (bekannt aufgrund der von CMake generierten Datei „compile_commands.json“ und auch, weil es keine der beschriebenen Probleme gibt unten, wenn es statisch direkt in eine ausführbare Datei () anstelle der folgenden .so) verknüpft ist.
Sagte, dass libWickedEngine_Linux.a in meinem Meson existiert .build suchly:

Code: Select all

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

Die gemeinsam genutzte Bibliothek von mir:
soll statisch in die endgültige Build-Ausgabe verlinken. So vollständig die obige .a< /code>. Es #includeist der „Einstiegspunkt .h“ der oben genannten Drittanbieter-Bibliothek in seiner eigenen just-helloworlding einzigen .cpp-Datei und sieht folgendermaßen aus:

Code: Select all

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

Das Problem:
Nun, wenn ich eine Meson-Kompilierung auf meinem meson.build mache (was wirklich einfach ist die oben genannten 2 zitierten Teile mit dem Präfix project('cWicked', ['cpp']) und dep_sdl2 = dependency('SDL2', include_type: 'system', static: false)), direkt danach Drucken der Verlinkung Ziel libcwicked.so Schritt, es gibt alle Arten von undefinierten Verweisen auf „“ Fehler durch ld, 100er oder 1000er, die aber trotzdem das Terminal überfluten. Ein kleiner Auszug:

Code: Select all

/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'

Aber hier geht es nicht nur um Lua, das sieht man, wenn man im Terminal nach oben scrollt: Genauso gilt es auch für viele andere eingebetteter Code von Drittanbietern.
Das Ziel hier ist, dass die .a des Drittanbieters vollständig in meiner .so landet und später nur noch von meinen Programmen übernommen wird und verlinken Sie letzteres. (Das eigentliche Ziel besteht darin, Letzteres zu einer dyn-verknüpfbaren C-API-Wrapper-Bibliothek anstelle der statischen C++-Bibliothek eines Drittanbieters zu machen, die von Natur aus nicht dyn-verknüpfbar ist.)
I' Ich bin noch ein bisschen neu in Meson und dem Erstellen von C/C++-Projekten mit mehreren Bibliotheken, daher habe ich wohl erwartet, dass alle in der .a-Datei vorhandenen Symbole irgendwie in die .so-Datei eingefügt werden Die Prozess namens „statisches Verknüpfen“ – wobei eine .so (oder DLL) genauso ein endgültiger Build-Artefakttyp ist wie jede ausführbare Datei. Ist das „prinzipiell nicht der Fall“ oder muss mein meson.build hier noch weiter optimiert werden?