Hallo, ich hab eine DLL für eine PXI-Relaykarte und würde Sie gerne mit
Qt benutzen. Die DLL hab ich schon erfolgreich in C# und Python benutzt,
aber ich muss die DLL nun in ein Qt Programm einbinden.
Das Qt Framework bietet dafür die QLibrary an, aber ich verstehe einen
Punkt nicht. Ich benutze als Qt Compiler MiniGW, wenn die DLL aber mit
einem anderen Compiler erstellt wurde, kann ich Sie dann trotzdem nutzen
oder bin ich angewiesen den gleichen Compiler zunutzen?
Du brauchst für deinen Compiler eine Import lib gegen die du linken
kannst. Wie du diese erstellen kannst sollte aus der Doc des Compilers
hervorgehen.
Stichworte wären zb impdef /implib zum erzeugen dieser lib.
Dann noch ein entsprechendes h File mit den Declarationen und fertig ist
die Laube.
Thomas
Thomas Z. schrieb:> Du brauchst für deinen Compiler eine Import lib gegen die du linken> kannst.
Nicht unbedingt:
http://www.mingw.org/wiki/CreateImportLibraries> Usually (read: for all DLLs created with MinGW and also a few others)> MinGW links fine against a DLL. No special import library is necessaryThomas Z. schrieb:> Dann noch ein entsprechendes h File mit den Declarationen und fertig ist> die Laube.
Man muss aufpassen welches ABI, welche C-Library und was für C++
Exceptions benutzt wurde. Die sind nicht unbedingt kompatibel.
>Du brauchst für deinen Compiler eine Import lib gegen die du linken>kannst. Wie du diese erstellen kannst sollte aus der Doc des Compilers>hervorgehen.>Stichworte wären zb impdef /implib zum erzeugen dieser lib.>Dann noch ein entsprechendes h File mit den Declarationen und fertig ist>die Laube.
Ich hab keine lib Datei, sondern nur eine DLL. Wie gesagt die DLL wurde
schon mit C# und Python in Projekten genutzt. Ich würde Sie nun gerne
mit QLibrary laden. Die dynamische DLL möchte ich nicht statisch linken,
sondern zur Laufzeit laden.
Die Frage, welche ich hab ist nun, ob ich mit MinGW als Compiler
weiterarbeiten kann oder ob ich zu einen anderen Compiler gezwungen
werde, weil die DLL mit einem anderen Compiler erstellt wurde.
Torben schrieb:> Die Frage, welche ich hab ist nun, ob ich mit MinGW als Compiler> weiterarbeiten kann oder ob ich zu einen anderen Compiler gezwungen> werde, weil die DLL mit einem anderen Compiler erstellt wurde.
Das kann man nicht sagen ohne zu wissen womit die DLL erstellt wurde,
welche C-Library sie nutzt und ob/welche Exceptions sie nutzt. Wenn sie
aus Python ging ist das schon mal ein gutes Zeichen.
Wenn du die DLL eh manuell öffnest spielt der Compiler keine Rolle mehr.
Das DLL Format ist ja vorgegeben. Du benutzt ja dann die QT Funktionen
die dir dann die Funktionen bereitstellen. Das wird intern wohl sowas
wie loadlibrary() sein.
Die Funktionen werden dann per Index oder Name angesprochen.
Thomas
Die gleiche Frage stellt sich auch für mich bei National Instrument
NI-DAQMX, welche ich auch gerne nutzen möchte.
Wenn ich mit die Unterhaltung hier anschaue, dann ist es mit minGw wohl
nicht so einfach möglich, weil die API in MS Visual C++ erstellt wurde.
https://forums.ni.com/t5/Multifunction-DAQ/Howto-use-NIDAQmx-with-mingw-gcc-3-4-2/td-p/294361?profile.language=en
Also werde indirekt zum MS Compiler gezwungen, wenn ich meine PXI DLL
und NI-DAQMx benutzen will?
Thomas Z. schrieb:> Wenn du die DLL eh manuell öffnest spielt der Compiler keine Rolle mehr.
Das hat nichts miteinander zu tun. Auch eine dynamisch geöffnete DLL
kann inkompatibel sein.
Niklas G. schrieb:> Das hat nichts miteinander zu tun. Auch eine dynamisch geöffnete DLL> kann inkompatibel sein.
Wenn es keine reine C- Schnittstelle ist, ja. Da sich diese aber in C#
und Python einbinden lies, gehe ich davon aus, das es eine reine C-
Schnittstelle ist.
Die C-ABI ist idR immer gleich. Wenn das also eine C-Library ist ohne
Name Mangling, sollte fast alles gehen.
Im Fall von C++ musst du idR zumindest unter Windows genau denselben
Compiler verwenden.
Der E. schrieb:> Du kannst die DLL auch dynamisch mit LoadLibrary einbinden:>> https://stackoverflow.com/questions/8696653/dynamically-load-a-function-from-a-dllThomas Z. schrieb:> Wenn du die DLL eh manuell öffnest spielt der Compiler keine Rolle> mehr.> Das DLL Format ist ja vorgegeben. Du benutzt ja dann die QT Funktionen> die dir dann die Funktionen bereitstellen. Das wird intern wohl sowas> wie loadlibrary() sein.> Die Funktionen werden dann per Index oder Name angesprochen.>> Thomas
Danke, ok das war mein Verständnis am Anfang auch, aber durch die
unterschiedlichen Antworten im Internet war ich mir unsicher.
Also wenn ich die Lib. lade mit QLibrary wie z.b. mit Python ctypes,
dann ist der Compiler welcher genutzt wurde egal. Wichtig ist nur die
gleiche Architektur zunehmen x86 oder x64?
>Wenn das also eine C-Library ist ohne Name Mangling, sollte fast alles >gehen.
Wie kann ich den herausfinden, ob es eine reine C DLL ist? Wie ich
herausfinden kann, ob es eine Managed / Unmanaged DLL ist, hatte ich im
Internet gefunden.
Sven B. schrieb:> Die C-ABI ist idR immer gleich. Wenn das also eine C-Library ist ohne> Name Mangling, sollte fast alles gehen.
Auch in C kann man Heap-Allokationen durchführen, welche bei
unterschiedlichen C-Libraries zu Konflikten führen können.
http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands> A new/delete or malloc/free in a MSVC DLL will not co-operate with a Cygwin
newlib new/delete or malloc/free. One cannot free space which was allocated in a
function using a different new/malloc at all.
Torben schrieb:> Wie kann ich den herausfinden, ob es eine reine C DLL ist?
Naja, besteht das API aus Klassen mit Funktionen, oder nur aus
Funktionen? Kann das API Exceptions werfen?
PS: MSVC-C-Libraries sind ja teilweise nichtmal zwischen verschiedenen
MSVC-Versionen kompatibel; alte libusb-DLLs lassen sich z.B. nicht mit
aktuellem MSVC linken.
Torben schrieb:> Also werde indirekt zum MS Compiler gezwungen
Das ist aber zum Glück nicht mehr so schlimm; als Community Edition
gibt's MSVC kostenlos und der Compiler ist nicht mehr ganz so schlimm
wie früher.
>Naja, besteht das API aus Klassen mit Funktionen, oder nur aus>Funktionen? Kann das API Exceptions werfen?
Nein, somit eine C DLL. Alles klar, danke.
>Nein die beschreiben ja dort den Umweg mit der Importlib. Das ist bei MS>übrigens ganz genauso. Nur das bei MS das ev in den Buildtools versteckt>ist oder der Anbieter schon entsprechendes bereitstellt.
Ok, nun wird einiges klarer. Danke.
>Das ist aber zum Glück nicht mehr so schlimm; als Community Edition>gibt's MSVC kostenlos und der Compiler ist nicht mehr ganz so schlimm>wie früher.
Richtig, aber bei kommerziellen Projekten wird man wohl VS kaufen
müssen, aber der Preis für die VS Pro ist jetzt noch überschaubar.
Was willst du mit QT bezwecken in diesem Fall?
Wenn es nur um GUI geht, warum benutzt du nicht deinen existierenden
Python Code zum kommunizieren mit der DLL und benutzt dort QT für den
Rest?
Oder musst du unbedingt die DLL per QLibrary laden? Der Grund erschließt
sich nicht wirklich.
Torben schrieb:> Hallo, nein es geht nicht nur um GUI. Die neue Applikation soll alles> vereinheitlichen und dafür bietet sich Qt an.
Das sollte mit einer Pythonlösung doch gehen, ich glaube hier scheint es
ein XY Problem zu geben.
