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!
Hat sich erledigt. Wir haben die zwei problematischen Dependencies nun unter anderem Namen gebaut und dynamisch gegen diese gelinkt. Funktioniert super.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.