Guten Abend,
wir setzen in einem Softwareprodukt für Windows SQLite mit der
Erweiterung libspatialite, um genau zu sein mod_spatialite, ein.
libspatialite besitzt, neben Anderen, Abhängigkeiten zu libiconv sowie
libz. Unser Produkt ist ein Erweiterungsmodul für ein closed-source
Softwareprodukt eines anderen Herstellers, das Produkt wird zur Laufzeit
durch die Drittanbietersoftware geladen. Die Drittanbietersoftware
bringt leider eigene Versionen von libiconv und libz, welche
inkompatibel mit libspatialite sind, und ein Laden der Erweiterung
verhindern.
So weit, so schlecht.
Unsere Idee war nun, einen Custom-Build von libspatialite zu erzeugen,
der gegen statische Bibliotheken (*.a) von libiconv und libz gelinkt
wird, sodass wir keine Abhängigkeiten mehr zu den jeweiligen dlls haben.
libspatialite hätten wir gern weiterhin als dynamische Bibliothek
(*.dll), die aber keine Laufzeitabhängigkeiten mehr zu zlib1.dll sowie
libiconv-2.dll haben darf. Alle weiteren dynamischen Abhängigkeiten
sollen so bleiben, wie sie sind.
Grundsätzlich können wir libspatialite inkl. der Abhängigkeiten mit
unserer Toolchain (msys2; mingw32; gcc 6.2) auch problemlos bauen. Auch
die statischen Builds von libiconv / libz waren kein Problem.
Problematisch wirds, wenn libspatialite quasi gemischt, zum Teil gegen
statische und zum Teil gegen dynamische Libs, gelinkt werden soll.
libtool gibt dann jedes Mal die folgende Warnung, und am Ende des
Prozesses fällt hinten keine dll heraus.
> *** Warning: This system can not link to static lib archive
> [...]/mingw32/local/lib/libiconv.la
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
Er jammert also, dass ihm die dynamische Varianten der Bibliotheken
fehlen. Die will ich ihm ja aber gerade nicht geben.
libspatialite wird wohl mit libtool gebaut. Wir haben an den Sourcen
nichts gemacht, lediglich die Übergabe der zu nutzenden Libs ist leicht
angepasst. In der Originalversion wurden die einfach per -liconv an den
Linker übergeben, inzwischen haben wir da schon ein paar Varianten
durchprobiert:
-L/mingw32/local/lib -l:libiconv.la
-Wl,-Bstatic -liconv
- und diverse Permutationen davon..
Fällt jemandem etwas dazu ein? Was machen wir falsch? Ich war irgendwo
auf einen nebulösen Forumseintrag von 2008 gestoßen, der aussagte, dass
libtool nicht gemischt gegen statische und dynamische Libs linken
könnte, kann das aber nicht so recht glauben. Hab dazu auch keine
Primärquelle gefunden.
Vielen Dank!
