Are DLL(s) that are meant to be "optional plugins" that the EXE is designed to open with dlopen or (on windows) GetModuleHandle or LoadLibrary.... are those sorts of plugins suitable for use in injectors? Nop But that supposes the that executable in question is a Qt-dependent executable in the first place. I guess you didn't explicitly mention that yet.... The process into which you attempt the injection... is that process any kind of Qt executable? Nop, it was not made with Qt. If not, then your injected code would (I believe) need to run a Qt event loop. Normally that would be done in the application's main. Im really really dumb with Qt, but i will try to do something with this information. It's just sad because i can't find any example of what i want :( Thanks

Hi, It works thanks :)

Hi, This stack overflow thread might be of interest to avoid having to play with the PATH environment variable.

Thank you @hskoglund for this option, it worked! This is the perfect solution for me, it's simple, and now I can use C++ variables for the install path of my DLL if needed. Thanks again!

@sierdzio I think you're second option is correct. I did dumpbin /dependents on both the debug and release versions of my util, and they have the same release QT dlls. I guess I never had to step into the QT code :-) . Usually, I get link errors when mixing debug with release, stemming from different array instrumentations. Sounds like QT was careful about this, to allow the mixing of debug with release -- unix-like.

@Yash001 said in why definition is talking from .cpp file?: why it is working if I will define the definition inside the class Because then the compiler sees the definition when you compile your executable. just now I try Q_DECL_EXPORT virtual QString GetExpParamTxt(QWidget*)const;. I got same error. You did not read the link carefully... you have to export it when compiling the lib, import it when linking against as explained.

Hello, Sorry, it took me a bit of time to make the tests: A simple "Hello world" project runs correctly in Qt Creator? When using the external lib, the program crashes. I suspect an incompatibility of this old lib with Windows 10. I need to further investigated this issue... Many thanks for your help!

@UnitScan seen on the official website (linked in the post you referring to): https://mediaarea.net/de/MediaInfo/Download https://mediaarea.net/de/MediaInfo/Download/Source https://mediaarea.net/de/MediaInfo/Download/Windows ...

@SGaist I am not using Labview's serial port directly because of my code contain many background functionalities. It will take time to implement all in Labview. We want to just give readable data and few User interface to Labview. So user can directly use readable value and interface in Labview.

@Bastien I build with MinGW on Qt Creator. And when I use DLL, I've the error. I didn't ask you that. I know that. That's why I asked you: And when you build it in Visual Studio you are using the MinGW compiler, not the MSVC one, just like you show you are using from Qt Creator, right? So I asked you what compiler you are using from Visual Studio, not Qt Creator. Having to make a guess and assuming you use MinGW from Qt Creator but MSVC from VS, I imagine that is precisely the answer to your: This code works fine in Visual Studio but not in QtCreator... Why ?

After few researches and some help from internal, it appears that my links to libraries ain't clean enough wich leads to those random behaviours. So i'm working on making it cleaner for x32/x64 debug and release. Thanks a lot for your help ! You made my mind way sharper !

Hi, One small correction: you can use Visual Studio 2017 with libraries built for VS2015, these two compilers are compatible (which is the first time two Microsoft Compilers are compatible).

Hi and welcome to devnet, Do you have any static QWidget based class in your library/application ?

I figured out my problem... I forgot to include the widget in the .lib.pro file...

Hi, Are you running them from Qt Creator ? If not did you deploy the QtMultimedia plugins for your second application ?

@koahnig SetName takes in a char* because it is a part of an API. @kshegunov Here are the relevant linker calls. I don't know how to get the .pro file from a VS project. Here is the linker call in the project that makes the dll: /OUT:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pdb" /DYNAMICBASE "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "qtmain.lib" "Qt5Core.lib" "Qt5Multimedia.lib" "Qt5Gui.lib" "winmm.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\3DRelease\yyy3D.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\lib\x64" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64" /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /TLBID:1 Here is the linker call for the project that uses the dll and has the run time error: /OUT:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pdb" /DYNAMICBASE "Qt5Core.lib" "Qt5Gui.lib" "Qt5Multimedia.lib" "yyy3D.lib" "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\AerieLib.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64/" /TLBID:1

Please have a look at the bug report I just submitted on this issue: https://bugreports.qt.io/browse/QTBUG-61059

You're welcome ! Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)

@MartinChan You need to find out what compiler was used to build the library

@hskoglund said in How to correctly deploy a modular Qt-Application on windows? (Contains: can not display svg-files in qml): You could check the list of directories from where Qt tries to load its plugins by calling QCoreApplication::libraryPaths() That looks like a cunning plan :) <insert Blackadder reference here> I played around with this information a bit and made the following observations: Dumping the library paths in the constructor of my module indeed lists only the module directory, but not the application directory. So I guess you mean the relative path when you say Your module_ui.dll inherits the search path from the .exe for .dlls Adding the application folder to the library search path within the module constructor solves the issue without the need for double-deployment Thanks a lot, you brought me on the right track.

Ignoring the Qt specific aspects of integrating a 3rd party library for just a moment, I would like to ask - are you implicitly or explicitly linking these DLLs into your application? Implicitly linking means (in case you don't know) means your code links with a *.lib that makes yours application need the DLL in order to run but also means you don't have to locate the functions you want to use in the DLL when your code runs. This is most likely the way you plan to use these DLLs. Explicitly linking means you don't do anything with the DLL until your application starts up - at that point your application code manually loads the DLL into its process space and your application code looks up the actual functions you want to use in the DLL. This is a very flexible way to use DLLs but you're probably not doing this.

@raven-worx said: Once the compilation is finished it should at least have created a library linker file (.lib for MSVC) and a dll file (if you chose the "shared" option) ok, after command mingw32-make install i get this structure of files: C:\taglib\bin\ libtag.dll C:\taglib\bin\libtag_c.dll C:\taglib\bin\taglib-config.cmd C:\taglib\include\ taglib\ .h files C:\taglib\lib\pkgconfig\taglib.pc C:\taglib\lib\pkgconfig\taglib_c.pc C:\taglib\lib\ libtag.dll.a C:\taglib\lib\libtag_c.dll.a copy these files (maybe also the header files from the include folder) somewhere to your projects folder and add it to your project: QtCreator / manually so i copied libtag.dll, libtag.dll.a and taglib folder to D:\qtproject\myprojectfolder then added win32: LIBS += -L$$PWD/ -llibtag INCLUDEPATH += $$PWD/ DEPENDPATH += $$PWD/ to .pro file and #include "taglib/fileref.h" #include "taglib/taglib.h" #include "taglib/tag.h" to .cpp file and it works!! great!! thanx =))

@koahnig said: Thanks for your patience and continued support. I have found the problem. That's great. I'm glad I was able to contribute. :) Unfortunately implementation files slipped into the compilation of the application. Ah, sneaky .cpps :) The warning text is misleading though, but it was actually showing the cause, duplicated declarations or better duplicated implementations. Sadly that's always the case with the linker. A linker is dumb as a shoe, it doesn't have any context or semantics to the code, it just reorders symbols and puts addresses, that's why linker error are so cryptic. :) I myself get into a hateful depression when I get the notorious "undefined vtable for ..." :D In any case, I'm glad it worked out. Cheers!

Thx,and it is really simple to use add library guide to add in the .dll and .lib that I want. And what I found is that maybe most of situations didn't have a .dll file for debug mode（which you can simply tell from it if has a -d suffix）,but you can use the given ones in a release mode. thx again.

@Joel-Bodenmann Just an FYI for people that may stumble upon this topic. windeployqt picks the DLLs based on the PATH environment variable. That means putting $QT_INSTALL_DIR\Tools\mingw810_64\bin\ instead of C:\MinGW\bin will lead to windeployqt picking the DLLs that come with Qt. This approach requires removing the C:\MinGW\bin path from the environment variable. If you need to keep it there, maybe just put them both there and play with the order.

I'd like to include some final information to make this thread history. I had to use different classes (structs) for managed and native sides since they were not the same for the C++/CLI compiler. But I used a simple trick to define ingredients of these structs. This way I was able to sync the information between the managed and native world. Of course I had to use some wrapper code since the managed and native structs were living on different worlds.

@patxi Its quite ok but the poster has not been online for 10 month so you might have better luck just posting a new question regarding GammaRay and see what happens :)

@hskoglund Thank you very much, now it works. :)

@kshegunov Thank you very much for your reply! That actually worked out. @asanka424 Thank you for your suggestion. When I started trying to get this working that was the first thing I tried and I didn't succeed, sadly. However, I started a new project completely from scratch and now it works just fine using the method your described. Thank you for your help guys, highly appreciated!

@jsulm Thanks ! It's clear ! Yes, sorry for the lack of clarity, but it's as hard to explain for me as it's hard to understand for you :) By the way, thank you for your help, and your patience ! Have a nice day

Well, the first goal is not resolved, I still have to connect my extern functions with my QCamera object. I'll try to change the approach, throwing the QCamera object, and use QMediaService (tanks for the idea @kshegunov). If someone has an idea for me, dont hesitate. Have a nice day !

@Ni.Sumi It's no hassle at all. I've corrected a grammar mistake in the post, but the meaning should remain the same. :) Kind regards.

Use the "Topic Tool" button :)

the problem is solved or not?