Cannot load dll with QLibrary using Qt5

Tiago M.Pinto

Hi!

I have developed an interface that loads my dlls using QLibrary and it worked fine until I had to format my disk and install a new Qt version. Now, QLibrary::load() is always returning false.

I remember that during my previous Qt installation I read a topic that pointed out some issues with QLibrary and Qt5 versions. Therefore, I managed to install a Qt4 version and all worked as expected. However, the current Qt online installer only allows to install Qt5 versions and I am still strugling to install Qt4 from older available installers. Since I am a recent user of Qt I am stuck with installing and configuring compatible Qt versions and compilers.

That said, I would appreciate some help in the following questions:

Does QLibrary really have bugs with Qt5 versions and only works in Qt4 or below?
How could I install a Qt4 version with a compatible MinGW?
I there any good alternative to QLibrary in order to call functions from my dlls?

Thanks in advance.

Best regards,

Tiago

JKSH

@Tiago-M-Pinto said in Cannot load dll with QLibrary using Qt5:

If yes, the DLLs can only be loaded with an executable compiled with MSVC, right?

Usually, extern "C" means the DLL can be loaded with any executable compiled with any C/C++ compiler.

Since I am using minGW compiler, If it was used to compile the DLLs, could I solve my problem?

The best way to find out is to try it.

The DLLs have some functions that I need to use. My goal is to upgrade my program with no need to compile it again if new DLLs are available (the functions prototypes won't change). Is there any other library that I could use instead of QLibrary?

It doesn't sound like you need a library to use the DLL. Just add the header and library to your *.pro file, and then #include the header in your .cpp code and call the function directly!

Example: If you have these files...

C:\my3rdpartystuff\include\foo.h
C:\my3rdpartystuff\bin\foo.dll

...then add this to your *.pro file:

INCLUDEPATH += "C:/my3rdpartystuff/include"
LIBS += -L"C:/my3rdpartystuff/bin" -lfoo

[EDIT: Trailing slashes removed from the 2 lines above]

If there are any problems, the compiler and linker will tell you.

Christian Ehrlicher

@Tiago-M-Pinto said in Cannot load dll with QLibrary using Qt5:

Does QLibrary really have bugs with Qt5 versions and only works in Qt4 or below?

No

How could I install a Qt4 version with a compatible MinGW?

Don't do it - Qt4 is no longer maintained, use Qt5

I there any good alternative to QLibrary in order to call functions from my dlls?

Use WinAPI or QLibrary - but I would guess both will not work since a dependency is not available - take a look with Dependency Walker what you library needs. QLibrary also has some functions to get the error code.

Tiago M.Pinto

@Christian-Ehrlicher Thanks for the reply.
I have just made a clean installation of Qt 5.14 and QLibrary still cannot load the dlls, either for a 32 or 64 bit compilation. I put the dlls in the build directory and the corresponding errorString returns: "Cannot load library xxxxxx: The specified module could not be found."
In addition, despite not being able to load my dlls, I can run my program outside QtCreator when I provide the misssing Qt dlls. However, the Dependency Walker still gives several errors regarging API-MS-WIN and EXT-MS-WIN modules.
What could be the problem here?

aha_1980

Hi @Tiago-M-Pinto,

Cannot load library xxxxxx: The specified module could not be found."

You always have to read that as "The specified module OR one of it's dependencies could not be found." Also note, that 64 bit apps need 64 bit DLLs and vice versa for 32 bit. Dependencies might be something as simple as compiler runtime libs.

However, the Dependency Walker still gives several errors regarging API-MS-WIN and EXT-MS-WIN modules.

Are these with yellow question marks? I guess they are harmless, I've seen lot's of them on current Windows 10. Probably Dependency Walker is too old.

Regards

Tiago M.Pinto

Hi @aha_1980 ,

You always have to read that as "The specified module OR one of it's dependencies could not be found."

How can I know which dependecies are these? Do I have to provide the path for them? How?

Also note, that 64 bit apps need 64 bit DLLs and vice versa for 32 bit. Dependencies might be something as simple as compiler runtime libs.

In my previous Qt installation my 64 bit app was loading the DLLs, so I do not see any reason why this should now be a problem. Just in case, I also compiled my app as 32 bit and the DLLs won't load.

Are these with yellow question marks? I guess they are harmless, I've seen lot's of them on current Windows 10. Probably Dependency Walker is too old.

Yes, but if other DLLs from Qt are missing, the marks are the same... can I still ignore those API-MS-WIN and EXT-MS-WIN errors anyway? You can see below a print screen of my Dependency Walker.

aha_1980

@Tiago-M-Pinto

Please collapse all the EXT-MS-* and API-MS-* entries. Then you'll see the real problematic ones.

How can I know which dependecies are these? Do I have to provide the path for them? How?

With Dependency Walker, e.g. Either copy the deps to the program or provides them with the PATH variable.

Btw., for deployment please use https://doc.qt.io/qt-5/windows-deployment.html

Regards

artwaw

Hi,
this also might be of help: you can check locations where your program searches for libraries using QCoreApplication::libraryPaths() - you can (for test) set to print them from main.cpp. This way you can check if the path you have them in is being searched for.
Anyway, as @aha_1980 said, core libs should not be a problem when you use the approach linked above, for 3rd party libs checking library paths might be a huge help (you can modify those but please read the documentation first, it is easy to mess up them).

Tiago M.Pinto

Hello @artwaw, thank you for the help.
I printed the searching locations as you said and my program is searching in my build directory where I have the DLLs. So, I am still wondering what's wrong...

artwaw

@Tiago-M-Pinto The only thing that comes to my mind is that the lib version (or type, confused 32/64bit) is mismatched. Maybe some more experienced member of the community will be able to provide more help?

Tiago M.Pinto

@aha_1980

Please collapse all the EXT-MS-* and API-MS-* entries. Then you'll see the real problematic ones.

After searching for errors different than EXT-MS-* and API-MS-*, I found that hvsifiletrust.dll and IEShims.dll were missing. I do not know if they could be ignored so I downloaded them from the web and put them in my program directory but it still does not work.

Tiago M.Pinto

@artwaw I just found out that my 3rd party DLLs were compiled using MS Visual Studio (probably MSVC). Could this be the problem since I am compiling my program with MinGW?

artwaw

@Tiago-M-Pinto Yes. They need to be recompiled with minGW or you should compile your program using MSVS.

Tiago M.Pinto

@artwaw OK, thank you. I will try to do that. However, I was using the same DLLs before while compiling my program with MinGW and everything worked just fine. How could that be?

artwaw

@Tiago-M-Pinto Can't say. There must be differences in how the library exposes the data but I have very little knowledge on how exactly they differ - I tried MSVC once and ran away screaming, minGW is so much easier on Windows. Me myself I always use minGW for everything on Windows and it just... works.

JKSH

@Tiago-M-Pinto said in Cannot load dll with QLibrary using Qt5:

@artwaw I just found out that my 3rd party DLLs were compiled using MS Visual Studio (probably MSVC). Could this be the problem since I am compiling my program with MinGW?

You didn't say if the 3rd-party code is written in C or C++.

If they are C++ DLLs, then they must use compatible compilers because of Name Mangling.

C DLLs don't have name mangling so they can be mixed.

I put the dlls in the build directory and the corresponding errorString returns: "Cannot load library xxxxxx: The specified module could not be found."

You said you "put the DLLs in the build directory"...

What is the absolute path of that dirrectory?
What path did you give to QLibrary?
What does QDir::currentPath() give you right before you initialize your QLibrary?

Finally, what are the DLLs that you're loading? Do you really need QLibrary? Could you link the DLLs directly to your executable instead?

Tiago M.Pinto

Hello @JKSH, thank you for your reply.

You didn't say if the 3rd-party code is written in C or C++.

The 3rd-party code is written in C and its header file is written in this way:

#ifdef __cplusplus
extern "C" {
#endif

#ifdef DLLEXP_UTIL
__declspec(dllexport)
#endif
void myFunc(void);

#ifdef __cplusplus
}
#endif

I presume the keyword __declspec(dllexport) is from MSVC. If yes, the DLLs can only be loaded with an executable compiled with MSVC, right?

Since I am using minGW compiler, If it was used to compile the DLLs, could I solve my problem?

What is the absolute path of that dirrectory?

C:\Users\Tiago\Google Drive\Projects\build-project-Desktop_Qt_5_14_1_MinGW_64_bit-Release

What path did you give to QLibrary?

To load the DLLs I only gave their name in the code becasue (as I already posted here) the directory above is included in the search paths.

What does QDir::currentPath() give you right before you initialize your QLibrary?

It gives me the directory above.

Finally, what are the DLLs that you're loading? Do you really need QLibrary? Could you link the DLLs directly to your executable instead?

The DLLs have some functions that I need to use. My goal is to upgrade my program with no need to compile it again if new DLLs are available (the functions prototypes won't change). Is there any other library that I could use instead of QLibrary?

SGaist

Hi,

If you want to use the export/import part, it's a bit more complicated than just __declspec. Take a look at the Creating Shared Libraries chapter in Qt's documentation.

JKSH

@Tiago-M-Pinto said in Cannot load dll with QLibrary using Qt5:

If yes, the DLLs can only be loaded with an executable compiled with MSVC, right?

Usually, extern "C" means the DLL can be loaded with any executable compiled with any C/C++ compiler.

Since I am using minGW compiler, If it was used to compile the DLLs, could I solve my problem?

The best way to find out is to try it.

The DLLs have some functions that I need to use. My goal is to upgrade my program with no need to compile it again if new DLLs are available (the functions prototypes won't change). Is there any other library that I could use instead of QLibrary?

It doesn't sound like you need a library to use the DLL. Just add the header and library to your *.pro file, and then #include the header in your .cpp code and call the function directly!

Example: If you have these files...

C:\my3rdpartystuff\include\foo.h
C:\my3rdpartystuff\bin\foo.dll

...then add this to your *.pro file:

INCLUDEPATH += "C:/my3rdpartystuff/include"
LIBS += -L"C:/my3rdpartystuff/bin" -lfoo

[EDIT: Trailing slashes removed from the 2 lines above]

If there are any problems, the compiler and linker will tell you.

aha_1980

@JKSH, that is a very good post!

Just one addition:

INCLUDEPATH += "C:/my3rdpartystuff/include/"
LIBS += -L"C:/my3rdpartystuff/bin/" -lfoo

It might be useful to omit the trailing slashes for the directories.

INCLUDEPATH += "C:/my3rdpartystuff/include"
LIBS += -L"C:/my3rdpartystuff/bin" -lfoo

On Windows these are converted to backslashes and can cause problems on line ends, for example.

Regards

Tiago M.Pinto

@JKSH, thank you again.

The best way to find out is to try it.

I compiled a simple DLL using minGW and it finally worked using QLibrary.

It doesn't sound like you need a library to use the DLL. Just add the header and library to your *.pro file, and then #include the header in your .cpp code and call the function directly!

You are right, I will do that. I didn't think about it but it... that way I can avoid resolves using QLibrary.