Qt statisch linken?

[DualCoreCpu]

Zitat:

Zitat von Rollo62 (Beitrag 1460454)

Zitat:

Wie funktioniert so ein statischer Import?

Vermutlich gar nicht, ich kenne mich mit dem QT-Linker jetzt nicht aus,
aber es ist wohl sehr wahrscheinlich das die Binärcodes völlig inkompatibel sind.
Wenn schon VC und C++Builder nicht zusammenpassen.

Ein Linken könnte vielleicht über einen kleinen Wrapper auf die QT-"Dll" gemacht werden.

Du schreibst von Linux/Macos zu EXE, also vermischt Du hier Windows/Linux ?
Ich vermute mal das es dann nicht um "DLL" sondern um .so/.dylib geht.

Ich frage, weil ich mehrere statische Bibliotheken in ein Freepascal Projekt einbinden will. Das Projekt soll OpenSource werden, die Bibliotheken sind auch alle OpenSource und sollen dann im Projekt mitgeliefert werden. Aufrufkonvention ist stdcall. Ich weiß, dass die Syntax für die external Deklaration sich für statische Bibliotheken von der bei DLLs unterscheidet. Biher werden meine Bibliotheken nicht gefunden, obwohl ich den Bibliothekspfad korrekt angegeben habe, sicherheitshalber die Bibliotheken nochmals in das BIN Verzeichnis von Freepascal und nochmals in den Pfad meines Projektes kopiert habe. Ich habe nun die gemagelten Namen aus den Bibliotheken mit vorangestelltem Unterstrich und der Bytezahl der übergebenen Parameter hinter external geschrieben. Wie stelle ich nun sicher, dass das statische Linken auch jederzeit funktioniert. Ich nutze Freepascal 3.0.4. Objektformat ist COFF.

Delphi-Quellcode:

function MyLibfunc(Param: Longint): Boolean;
  stdcall; external name '_MyLibfunc@4';

Wenn ich ...external name 'MyLibfunc' schreibe, wird die Bibliothek nicht gefunden, also muss es neben den gemangleten Namen noch was anderes sein, was das Linken fehlschlagen lässt. Aber was?

In der IDE habe ich statisches Linken eingestellt.

.

[himitsu]

Nja, der Begriff ist im deutschen bissl doppelt verwendet.

Es gibt den Compiler, der macht aus Code das Binäre (compile)
und dann gibt es den Linker, der macht aus den binären Teilen und den Ressourcen die fertige Datei. (link)
Im Delphi ist beides im DCC drin.

Und dann kann man Funktionen von DLLs verlinken importieren,
entweder dynmaisch (LoadLibrary+GetProcAddress) oder statisch über die Importtabelle (external) einen Link/Verweis auf die jeweilige DLL.


Egal welche Sprache, wenn deren Compiler eine .OBJ-Datei erstellen kann, dann kann deren compilierter Code im Delphi gelinkt werden,
und wird somit direkt in die EXE eingebaut (vom Linker mit reingezogen).
http://docwiki.embarcadero.com/RADSt..._file_(Delphi)
Siehe z.B. die Units mit ZLib, RegEx und PNG, im Delphi. (System.ZLib.pas)

[Andreas13]

Leider kann ich kein C, daher kann ich nicht beurteilen, ob dem TE dieser Link https://social.msdn.microsoft.com/Fo...from-dll-files helfen würde: Aus seiner .DLL lässt sich angeblich .OBJ machen und die OBJ-Files kann Delphi in die Exe Linken, wie himitsu unter #12 bereits erwähnt hat.
Grus, Andreas

[DualCoreCpu]

Danke erst mal für die Antworten. Leider gewinne ich aber den Eindruck dass in diesem Forum die DLL noch mal als .obj Datei neu übersetzt wird.

Ich aber will wissen wie es danach weiter geht, wenn ich die statische Bibliothek bereits habe. In meinem Fall liegen die Bibliotheken in Assembler vor, Aufrufkonverntion dennoch STDCALL. Und zu allem Übel auch noch im :LIB Format, nicht als .OBJ!

Nun geht es darum, wie meine external Definition aussehen muss, die unterscheidet sich zumindest in Freepasacl von derjenigen bei DLLs.

In Freepascal:

{$linklib mylibrary.lib} //Meine aktuellen Bibliotheken die ich linken will, liegen im .lib Format vor

oder

{$L mylibrary.lib} //Diese Form kenne ich noch aus Turbo Pascal Zeiten, dort aber mit ,obj Dateien, statt .lib Dateien

Damals hat man dann die Bibliotheksprozedur so geschrieben und die Obj Datei dazu gelinkt:

procedure myLibProc(myParam: mytype); external;
{$L mylibrary.obj} //hier nun unterhalb der Bibliotheksfunktion die Verlinkung der die Funktion enthaltenden Bibliothek.

Nun hab ich aber eine .LIB Datei mit vielen Bibliotheksfunktionen vorliegen, die auch aus mehreren .obj Dateien stammen, die zu dieser.lib Bibliothek zusammengefasst sind.

Kann ich da genau so vorgehen wie bei reinen .obj Dateien?

[delphi]
procedure proc1; external;
{$L mylib.lib}

function func1: Integer; external;
{$L mylib.lib}

function func2(param1: PChar): PChar; external;
{$L mylib.lib}
[/quote]

Ich habe schon mehrere Varianten ausprobiert, die alle nicht zum Erfolg führen.

Verwendet hier Freepascal dieselbe Syntax wie Delphi?

Abgesehen davon, dass Delphi die Funktions- und Procedure Köpfe sowohl im INterfaceteil der Unit und im Implementationsteil und nur dort mit den EXTERNAL Deklarationen aufführt, während Freepascal die Funktions und Proceure Köpfe nur im Interface Teil und dort dannn mit den External Deklarationen aufführt. Mit geht es hier um die weitere Attribute NAME <libname> ...

Also:

Delphi-Quellcode:

function myfunc: mytype; stdcall; externel dllname name 'myfunc';

für dlls.

und

Delphi-Quellcode:

function myfunc: mytype; stdcall; externel name '_myfunc@0';

//wenn statisch zu linken

So habe ich es jetzt in meinen Interface Units. Die Bibliothek mit den Funktionen linke ich zu Beginn des Codes im Interface Teil nach der Uses Klausel, sonst nirgends mehr.

Gibt es noch eine andere Möglichkeit? Oder muss ich die {$L ...} oder {$Linklib ...} Anweisung unter jede einzelne Funktion schreiben?

Wenn ich nämlich den unmangled name "myfunc" verwende, findet der Linker meine Bibliothek(en) nicht, obwohl ich die sowohl im dem Linker übergebenen Verzeichnis, als auch sicherheitshalber nochmals in meinem Projektverzeichnis und dann nochmals im Bin Verzeichnis des Compilers liegen habe, wo ja auch der Linker ist. Warum werden also meine Bibliotheken nicht gefunden. Wenn ich die unmangled names verwende und das nicht geht, dann müsste doch die Fehlermeldung lauten: Falscher Funktionsname oder Funktion nicht gefunden, aber doch nicht Bibliothek nicht gefunden. Deshalb will ich das erst mal alles theoretisch durchspielen, bevor ich rumprobiere ob es denn nun cpmpiliert.

[himitsu]

Ja, die Funktionsdeklaration mit EXTERNAL muß gemacht werden. (ohne Angabe einer DLL, wie beim normalen Import)
Name der Funktion wie in der OBJ-Datei. Ich weiß nicht, ob hier auch eine Umbenennung möglich ist, so ala

Delphi-Quellcode:

procedure MeinName; external name 'DerenName';

.


LIB-Dateien kann man mit Delphi erstellen, aber nicht (direkt) verwenden.
Du mußt also die LIB-Datei erst umwandeln, um sie benutzen zu können.
Entweder aus der LIB eine OBJ machen, oder die LIB in eine DLL linken und dann normal importieren.

http://rvelthuis.de/articles/articles-cobjs.html
https://www.delphipraxis.net/177194-...verwenden.html
http://docwiki.embarcadero.com/RADSt...en_Anwendungen

[DualCoreCpu]

Danke @himisu, obwohl mir das gar nicht gefällt. Kann denn Freepascal .lib Dateien so direkt verwenden oder ist dort auch die Umwandlung nötig?

[himitsu]

Wollte erst "glaub nicht" sagen, aber grad noch entdeckt, dass es dort neben

Delphi-Quellcode:

{$LINK ...}

auch ein

Delphi-Quellcode:

{$LINKLIB ...}

gibt.

https://www.freepascal.org/docs-html/prog/progsu43.html
https://www.freepascal.org/docs-html...53-520001.2.46

Hmmm, man könnte nun auf die blöde Idee kommen mit FreePascal eine DCU zu erstellen, wo der Import drin steckt, aber diese DCU dann in Delphi verwenden zu wollen wird wohl nicht gehen. :cry: