DLL mit MinGW linken

Dlls werden dynamisch gelinkt, also genau nicht von ld.

Das macht der Programmlader des Betriebssystems, wenn das Programm 
ausgeführt wird, oder sogar das Programm selber über 
LoadLibrary/GetProcAddress.

Du willst vermutlich die erste Variante verwenden, dann musst Du mit den 
zu den DLLs gehörenden Importlibraries linken.

> Interessant ist, dass bei der Angabe von -lgtk-win32-2.0-0 mit dem
> Suffix -0 die Bibliothek gefunden wird.

Dann wird ziemlich sicher nicht auf die DLL, sondern auf die zugehörige 
Importlibrary zugegriffen, die nämlich endet entweder auf .lib oder auf 
.a

Peter II schrieb:
> es geht nicht one eine lib (.a) datei.

Würde mich wundern, entspricht nicht dem, wie der GNU-Linker sonst
arbeitet (unter Unix).  Dort benötigt man nur entweder eine
statische Bibliothek oder eine dynamische.  Sowie man eine
statische Bibliothek (.a) auf der Kommandozeile angibt, wird diese
auch statisch gelinkt.

Benny, gib' doch mal die Option -v mit an, dann sollte er etwas
gesprächiger werden.

Benny schrieb:
> Parameter:
> -lgtk-win32-2.0 -lgdk-win32-2.0 ...
Es fehlen die Angaben, wo die DLL-Dateien sind, z.B. per -L Flag. 
Dieses muss man aus der Ausgabe von pkg-config mitkopieren.

Benny schrieb:
> Sowei ich weiß werden Dateiversionen vom
> Compiler automatisch erkannt.
Unter UNIX ja, unter Windows nein.

Rufus Τ. Firefly schrieb:
> Dlls werden dynamisch gelinkt, also genau nicht von ld.
Doch, der Linker muss die Referenzen zur DLL einbauen. Das 
zusammenführen des Codes selber macht dann der Loader.

Benny schrieb:
> Ich habe keine .a oder .lib-Dateien vorliegen.
Rufus Τ. Firefly schrieb:
> Du willst vermutlich die erste Variante verwenden, dann musst Du mit den
> zu den DLLs gehörenden Importlibraries linken.
Korrekt; wobei mingw32 heutzutage auch ohne Importlibrary (.a) 
funktioniert, d.h. alleine mit der DLL.

Benny schrieb:
> Muss ich ihm noch mitteilen, dass
> es sich um dynamische Bibliotheken handelt?
Nein. Testweise ist es immer gut, einfach den kompletten Pfad zur 
Library (ob .so, .a oder .dll) dem gcc/g++ -Aufruf zu übergeben (ohne 
-l). Wenn das klappt, hast du nur ein Dateifindungsproblem. Wenn das 
auch nicht klappt, ist mit der Library selbst was kaputt.

Peter II schrieb:
> es geht nicht one eine lib (.a) datei.
Mit neuerem MinGW32 schon.

Peter II schrieb:
> der du musst es im Programmcode
> mit LoadLibrary und GetProcAddress machen.
Sehr nervig.

Jörg Wunsch schrieb:
> Würde mich wundern, entspricht nicht dem, wie der GNU-Linker sonst
> arbeitet (unter Unix).
Es geht ja auch um Windows. Peter II hat insofern Recht, dass Microsofts 
Linker immer eine Importbibliothek (.lib) benötigt, welche im Endeffekt 
eine einfache statische Library ist, die die Funktionsaufrufe an die DLL 
weiterleitet. Aber mit MinGW32 ist das wie gesagt glücklicherweise kein 
Problem.

Ich habe unter http://gtk.2g2s.de/ ein Windows-Binary einer 
Gtk+3-Version erstellt, dass sich mit pkg-config nutzen lassen sollte.
Es ist aber so, dass das Gtk -Team scheinbar keine Lust mehr auf 
Windows-Support (sowie auf mein Gtk-Windows-Paket) hat; es empfiehlt 
sich daher die Nutzung von Qt.

Niklas Gürtler schrieb:
>> Würde mich wundern, entspricht nicht dem, wie der GNU-Linker sonst
>> arbeitet (unter Unix).
> Es geht ja auch um Windows.

Die mingw32-Tools gehen ja auch unter Unix. ;-)  (Crosscompiler)

Ich glaube mich auch zu erinnern, dass ich damit auch schon gegen
normale DLLs (ohne .a) gelinkt habe, aber völlig sicher bin ich
mir da nicht.

LoadLibrary("blubb.dll")
so glaube ich es mit ICMP.dll gemacht zu haben

Timmo H. schrieb:
> LoadLibrary("blubb.dll")

Das ist aber manuelles Laden zur Laufzeit.

Was Benny will ist, dass die DLL automatisch beim Programmstart
geladen (oder referenziert) wird und dann in der Applikation
benutzt werden kann, als wäre sie statisch gelinkt.