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.

I am grateful that I came across this thread. It exactly solved my problem.

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 :)

@hskoglund i decided to throw off their problem and the code here, can someone else help
#include <QApplication>
#include <QAxWidget>
QAxWidget *drvFR;
#define CLSID_DrvFR "{450E3DC0-5370-4007-BD5F-90827EC2C2D6}" // it's GUID for driver object (my Addin.MifareDrv). GUID can be found in registry
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
drvFR = new QAxWidget();
drvFR->setControl(CLSID_DrvFR);
drvFR->dynamicCall("FindDevice()");
drvFR->dynamicCall("Connect()");
drvFR->setProperty("BeepTone", 1);
drvFR->dynamicCall("PcdBeep()");
....
and of course in .pro write QT += axcontainer.

Thank you for trying help.

You should check this: http://doc.qt.io/qt-5/windows-deployment.html
Especially the "The Windows Deployment Tool" part.

Hi,

Yes that helped me, thanks a lot.

It's rarely needed to call unload.

@JKSH It is latest version of MinGW. But everything works fine with Qt version of MinGW. Thank you so much for help!

@SGaist
C:\Qt\Qt5.5.0\5.5\msvc2013\include\QtCore\qobject.h:40: error: C1001: An internal error has occurred in the compiler.

What do you mean by "other dependency for qwindows.dll"? I only have that one, in the platforms subfolder. Copying it into the exe folder doesn't change anything...

Simple Method..

From the desktop, right click the Computer icon.

Choose Properties from the context menu.

Click the Advanced system settings link.

list item Click Environment Variables. In the section System Variables, find the PATH environment variable and select it. Click Edit. If the PATH environment variable does not exist, click New.

In the Edit System Variable (or New System Variable) window, specify the value of the PATH environment variable example(C:\Qt\Mingw32\bin). Click OK. Close all remaining windows by clicking OK

IIRC, you can also use

extern "C" { #include "mycinclude.h" }

@SGaist said:

@sierdzio Indeed the back ticks are not mandatory, however it gives the forum engine a good hint of what is following

in the cheat sheet you can actually find:
Blocks of code are either fenced by lines with three back-ticks ```, or are indented with four spaces. I recommend only using the fenced code blocks -- they're easier and only they support syntax highlighting.

The question is what is the syntax highlighting now?

@danks_
That is good to hear !
Could also been some kind of setup problem with 5_5 but yeah it does
seems like a bug.

I will try with 5_5 and see it it fails for me too.

update:
Tested win pure 5_5 install
It worked by copying the DLLs ! ?
Even worked with no sub sqldrivers folder ...!
(in the release folder)

But when moved out of the virtual machines
it did want the sqldrivers folder to work.

So the current version of 5.5 via the online installer does seems to work in regards to sql.?!

Yes it should.

Visual Studio rule number one: Everything must be compiled with the same version of Visual Studio.

The different versions of Visual Studio are not compatible one with the other.