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
:
Bearbeitet durch User
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 necessary Thomas 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.
Du kannst die DLL auch dynamisch mit LoadLibrary einbinden: https://stackoverflow.com/questions/8696653/dynamically-load-a-function-from-a-dll
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.
:
Bearbeitet durch User
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-dll Thomas 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?
:
Bearbeitet durch User
Torben schrieb: > 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? 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. Thomas
:
Bearbeitet durch User
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.
Hallo, nein es geht nicht nur um GUI. Die neue Applikation soll alles vereinheitlichen und dafür bietet sich Qt an.
Sven B. schrieb: > Im Fall von C++ musst du idR zumindest unter Windows genau denselben > Compiler verwenden. Genau der selbe brauchts nicht zu sein, einer mit zugesicherter Binärkompatibilität sollte es tun. Wenn das C++-Interface entspechend gestaltet ist, klappt das auch mit anderen Compilern. https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL#CppMatureApproach Oliver
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.
Da es Qt auch für Python gibt, stellt sich die Frage nach "Python oder Qt" doch gar nicht. Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte 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.