Ich habe ein .cpp Projekt welches ich über ein mitgeliefertes makefile in .o Dateien kompiliere. Nun muß ich diese .o Dateien zu einer DLL linken. Der Author des Projektes schlägt folgende Zeilen vor:
dlltool -z sample_plugin.def sample_plugin.o
ld -shared -o sample.o sample_plugin.o sample_plugin.def …/…/lib/plugin.a
Zwar werden die Befehle ausgeführt, aber es entsteht keine .dll. Fällt vielleicht jemandem der Fehler auf?
Hallo,
dlltool -z sample_plugin.def sample_plugin.o
ld -shared -o sample.o sample_plugin.o sample_plugin.def
…/…/lib/plugin.aZwar werden die Befehle ausgeführt, aber es entsteht keine
.dll. Fällt vielleicht jemandem der Fehler auf?
ld -o
sorgt dafür, dass in die Ausgabe vom Linker in der datei erzeugt wird, bei dir also sample.o
Schau dir mal mit
file sample.o
an, was das für eine Datei ist.
Grüße,
Moritz
Moien
Zwar werden die Befehle ausgeführt, aber es entsteht keine
.dll. Fällt vielleicht jemandem der Fehler auf?
.dll gibt’s nicht unter linux, nur unter windows. Unter Linux/unix/… nennt sich sowas .o oder .so
cu
Du magst Recht haben, aber ich benutze ja grade Mingw als cross compiler, um eine unix Bibliothek im Link-Prozeß für ein Windows-Programm zu nutzen …
.dll gibt’s nicht unter linux, nur unter windows. Unter
Linux/unix/… nennt sich sowas .o oder .socu
Hallo,
Du magst Recht haben, aber ich benutze ja grade Mingw als
cross compiler, um eine unix Bibliothek im Link-Prozeß für ein
Windows-Programm zu nutzen …
Huch? Unter Crosscompiling verstehe ich, dass man für eine andere Plattform übersetzt als die, auf der der Compiler läuft.
Und bist du dir sicher, dass dein Vorhaben überhaupt prinzipiell möglich ist? Du bräuchtest ja alle Abhängigkeiten der Linuxbibliothek, inklusive (g)libc.
Grüße,
Moritz
Moien
Und bist du dir sicher, dass dein Vorhaben überhaupt
prinzipiell möglich ist?
Hab mir das gleiche gedacht und „Mingw“ mal in google gesteckt:
„MinGW: A collection of freely available and freely distributable Windows specific header files and import libraries combined with GNU toolsets that allow one to produce native Windows programs that do not rely on any 3rd-party C runtime DLLs.“
Er versucht also gerade einen CrossCompiler, der windows-binaries macht, unter linux mithilfe von gcc/ld zu compilieren.
uhm … von hinten durch die Brust, einmal um den Block in’s Auge ?
Wärs da echt nicht evtl. einfacher ein stinknormales windows zu installieren und einen stinknormalen windows C-Compiler zu nehmen ?
Du bräuchtest ja alle Abhängigkeiten
der Linuxbibliothek, inklusive (g)libc.
(g)libc ist nicht das Problem, da hat Microsoft das ± gleiche drin stehen wie linux. Aber wie wollen die an die interessanten Ding wie MFC rankommen ? Und wie soll man das unter Linux debuggen … oder muss man da jedesmal neu starten zum testen ?
cu
Natürlich habe ich als erstes Versucht, bequem mit Visual C++ zu arbeiten. Das Problem ist, dass ich für ein Plugin schreiben muß, welches wiederum eine Bibliothek braucht, welche mir nur im unix .a-Format vorliegt. Daher der Umweg über den cross-compiler. Auf diese Weise kann ich auch das make-skript mitverwenden.
Nun weiter zu meinem Problem, langsam krieche ich vorwärts: Ich habe ein „file“ über die sample.o rübergeschickt. Es wird tatsächlich als Windows-DLL identifiziert. Da beim Einbinden des Plugins jedoch die Methoden nicht gefunden werde (es wird also nicht korrekt geladen) mache ich mir über die Ursache gedanken.
In meiner Verzweiflung habe ich nämlich die .o Datei (identifiziert als DLL) einfach umbenannt und eingebunden. Das wird so einfach wahrscheinlich nicht funzen …
Moien
In meiner Verzweiflung habe ich nämlich die .o Datei
(identifiziert als DLL) einfach umbenannt und eingebunden.
Was ich ganz am Anfang mal vorgeschlagen hatte…
Nee, im Ernst: du solltest jetzt erstmal auf windows seite rausfinden was der DLL fehlt (auf linux-seite mal " string datei.dll | grep „.dll“ " drüberrutschen lassen und kucken). Die wird wahrscheinlich irgendwas nachladen wollen das in Mingw steckt.
cu