@Dariusz Hi Yes you can. see this example (and reads the docs SGaist links) https://doc.qt.io/qt-6/qtwidgets-tools-plugandpaint-app-example.html Here the drawing app is extended with extra plugsins. Do note, however, that you will need to do as sample does in "The next step is to load dynamic plugins" where is enumerate the files in a given folder using const auto entryList = pluginsDir.entryList(QDir::Files); for (const QString &fileName : entryList) { QPluginLoader loader(pluginsDir.absoluteFilePath(fileName)); ... so its not 100% automatic but almost ;)

i can confirm i have same issue (so far unsolved), doing tips from @Christian-Ehrlicher did not help

@UvQtcYZJuD7J5VW7 said in Dependencies missing after DLL compilation: Unfortunately, LabView is not very talkative. This is the only error message I get. I have already recreated the node. Ah, check the dependencies of the DLLs that you deployed. For example, libgcc_s_dw2-1.dll depends on other DLLs too. Otherwise I could programming the entire program in Qt and so I will not have the need to use a DLL. If you can do everything in 1 language, that makes life a lot easier.

Do you mean how to add paths so that your .exe files can be run from Qt Creator, or adding paths so that your .exe files can be run without Qt Creator? In the first case (starting .exe files from Qt Creator) as long as you only have a single version of Qt installed on your PC, there should be no need to add any paths, as I said earlier, Qt Creator adds the path to the Qt dlls for you. In the second case (starting .exe files without Qt Creator) then there are 2 ways to do it: copy the Qt dlls to the same directory that your .exe file is in, either manually or by using the windeployqt.exe program adding the path to the Qt dlls to the PATH env. variable Note: LIBS += -LMyPath has no effect on runtime lookup of .dlls or .so files QMAKE_RPATHDIR has no effect on Windows, because Windows does not support adding a list of paths to your .exe/elf file where to find the Qt dlls/so files (works only on Linux and MacOS) Also on Linux, QMAKE_RPATHDIR is not needed for the first case (starting .exe/elf files from Qt Creator) since Qt Creator does that automatically for you (by issuing a linker command e.g. -Wl,-rpath,/home/user/Qt/5.15.2/gcc_64/lib)

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!

@raven-worx do you know of any project to "Qt-ize" the interface? Currently they use their own String class, which makes working with it difficult

@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.

@tostrizek Here's my shell script for setup in git bash (mingw) #!/bin/bash # use " source ./setup.sh " to execute export PATH=/c/Qt/5.15.2/mingw81_64/bin:$PATH export PATH=/c/Qt/Tools/mingw810_64/bin:$PATH export PATH=/c/Qt/Tools/QtInstallerFramework/4.1/bin:$PATH

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.

@jsulm the question is solved,Thank you very much

@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