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