Qt5.8 static failes on windows 7 or lower, functioning on windows 10

JoVR

It does start.

A main function of the application is that it opens a DLL and runs through some predefined functions.
The DLL is also of my own design so I know its workings etc.

On the Windows 10 it just calls open it with the QLibrary without any problems.
But on the Windows 7 I get the message that the module in "*/App/DLL's/lib.DLL" (abstraction) is not found/could not be opened.

The DLL is there, in the right place.

BTW I'm having the same problem on Android, where some version can open it and others can't.

JoVR

@jsulm Sorry for being so cryptic. I'm still running some tests to further pinpoint why it won't function but as of now the QLibrary seams to be the only problem.

hskoglund

Hi, just guessing but that DLL of yours, is it dependent on some other DLL (perhaps a Microsoft DLL) that's not present in Windows 7?

JoVR

Nope, definitely not. Except for:

#include <stdexcept>
#include <stdlib.h>
#include <string>
#include <iostream>
#include <sstream>

it only contains specific conversion functions for a machine we develop.
So to simplify, it just counts.

hskoglund

Ok, another question: have you tried a non-static (i.e. dynamic) Qt 5.8 build of you app, if it stops with the same error on Windows 7?

JoVR

@hskoglund

No not yet. I'll try that next.

JoVR

@hskoglund
Tried it but gave me the same result. My application catches the error so it doesn't just stop or crash.
It just can't read any of the DLL's I point it to.

Also tried it as local admin as well to make sure it's not some hidden unauthorized action error.

QLibrary seems to be missing something. I don't have any clue where to look.

Any suggestions?

hskoglund

Well Dependency Walker is always a good tool to use, you could try loading your app first in Windows 10, hit F7 for a trace of a successful run, then perform the same incantation in Windows 7 and see where the trace (hopefully) differs.

Also, if your DLL does any graphics output, make sure it doesn't use DX12 or Direct3D12 (not supported in Windows 7).

JoVR

@hskoglund
Thanks for the tip.
With it I pinpointed the problem with the LIBWINPTHREAD-1.DLL
Which is not found in the windows 7 systems.

It is found on my development system in the QT installation.
Packing it with the application solves the problem. yippie

I'm presuming that to statically package it with my application will require me to rebuild Qt?

hskoglund

Good to hear you found the culprit!
About rebuilding the static Qt to include that .dll, you shouldn't have to compile all of it again, just do the linking steps. But don't quote me on this, I haven't tried a static build myself yet :-)

P.S. I googled and found this StackOverflow post where someone mentions a stunt to make sure libwinpthread-1.dll is included in your static build; and that's to (dummy) use some functionality from it like <thread> in C++11 in your program.