Unsolved Can I use Qt5.5.1mingw492_32 in an application compiled with mingw482_32 as shipped with Qt?

[panca]

We need to compile an application with MinGW482_32 because the compile breaks using MinGW492. The application makes heavy use of Qt.

I built using QtCreator using a kit combining Qt5.5.1mingw492_32 and MinGW482_32 (both obtained via the qt.io online installer). QtCreator automatically adds Qt5.5.5/bin and mingw482/bin (in that order) at the head of the search path in the build-environment.

The resulting build uses the MinGW runtime libraries shipped with Qt5.5.1 (as is to be expected because of the order of elements in the path). And the build seems to work! Initial testing produces no errors that point to any runtime incompatibilities. If I exchange the runtimes (libstdc++-6.dll, libgcc_s_dw2-1.dll and libwinpthread-1.dll) by the ones shipped with MinGW482, I get instant errors related to these libraries.

My question: is compiling an application with MinGW482_32 using Qt5.5.1mingw492_32 clean? Are the runtimes kind of "downwards compatible"?

If the answer is "not sure" - how could I verify that it is okay in my case? Is already enough to see that the app successfully starts or are other tests required?

[jsulm]

"because the compile breaks using MinGW492" - so you have compile errors?
Wouldn't it be better to fix the code instead of using different compiler?

One note: you can build Qt with the same compiler you want to use for your application.

[panca]

@jsulm

Wouldn't it be better to fix the code instead of using different compiler?

Sure, but we have a narrow time frame, right now it's not an option. My enquiry is more of a pragmatic nature.

One note: you can build Qt with the same compiler you want to use for your application.

True, but sounds like a daunting task, and would force us to not use the official release.

Maybe I should restate my question: is there a way to tell if this can be expected to work reliably? Is there some concept of "downwards-compatibility" between mingw492 and mingw482 runtime libraries?

Thanks for your reply!

[kshegunov]

@panca said:

Maybe I should restate my question: is there a way to tell if this can be expected to work reliably?

If the symbols are compatible it should work, this however this I can in no way guarantee.

Is there some concept of "downwards-compatibility" between mingw492 and mingw482 runtime libraries?

I doubt it, at least there's no rigid rule to my knowledge.

If I exchange the runtimes (libstdc++-6.dll, libgcc_s_dw2-1.dll and libwinpthread-1.dll) by the ones shipped with MinGW482, I get instant errors related to these libraries.

You could try checking if there's a difference between the symbols. I think the dll doesn't contain a stub specifying which binary is to be used exactly, but I'm not an expert on the subject, as I develop on Linux. Maybe look up the .dll header structure and see if there's something suspicious that the loader might use to distinguish between the two binaries. Also it might be useful to specify what errors exactly are you getting.

Kind regards.

[panca]

@kshegunov said:

You could try checking if there's a difference between the symbols. I think the dll doesn't contain a stub specifying which binary is to be used exactly, but I'm not an expert on the subject, as I develop on Linux. Maybe look up the .dll header structure and see if there's something suspicious that the loader might use to distinguish between the two binaries. Also it might be useful to specify what errors exactly are you getting.

Thank you, kshegunov! I could reproduce the errors again (startup messages) if that would help to clear up issues, but my main interest is actually not to make qt5.5.1 work with the 4.8.2 MinGW runtime libs, but to verify the opposite: is it fine to use the Qt-5.5.1 provided 4.9.2 runtimes with an application that was compiled with (Qt provided) MinGW 4.8.2 (linking to Qt 5.5.1mingw492).

I guess there is no strict answer, so my question would have to be: if the application comes up normally, is that already enough to tell it works (have the necessary dll checks already been done), or is more testing required?

Thanks for your help!
.r.

[kshegunov]

@panca
Hello,

I could reproduce the errors again (startup messages) if that would help to clear up issues

This might be helpful, indeed.

but to verify the opposite: is it fine to use the Qt-5.5.1 provided 4.9.2 runtimes with an application that was compiled with (Qt provided) MinGW 4.8.2 (linking to Qt 5.5.1mingw492).

As I said I think the runtime should be compatible, but short of trying it out I have no way (or the knowledge) to tell for sure.

if the application comes up normally, is that already enough to tell it works (have the necessary dll checks already been done), or is more testing required?

If the loader is able to resolve the symbols (meaning you don't get windows system error messages before the application starts), then I'd say yes - this should be enough to know that it works and will (most probably) work.
Do note that this is borderline loader abuse, so there are no guarantees

Kind regards.

[panca]

I could reproduce the errors again (startup messages) if that would help to clear up issues

This might be helpful, indeed.

Dear kshegunov,

thank you for your well considered response!

I promised to send the error messages. Sorry for a bit of delay! So when I open an application compiled with MinGW482_32 and linking to Qt 5.5.1mingw492_32, I get these system errors at start-up, if I use the runtime libraries from mingw482. As said the errors are gone when using the runtime libraries from mingw492:

All three start with: scide.exe - Entry point not found

scide.exe, based on Qt, is an editor for the sound synthesis tool SuperCollider.

First:
The procedure entry point __cxa_throw_bad_array_new_length could not be located in the dynamic link library
C:\Users.........\SuperCollider\Qt5Core.dll

Second:

The procedure entry point __ZSt24_throw_out_of_range_fmtPKcz could not be located in the dynamic link library
C:\Users.........\SuperCollider\Qt5WebKit.dll

Third:

The procedure entry point __ZSt24_throw_out_of_range_fmtPKcz could not be located in the dynamic link library
C:\Users.........\SuperCollider\Qt5Qml.dll

Thank you for any input

Best
Rainer

[kshegunov]

@panca
Hello,
I have two follow up questions:

1. Could you give a list of the names of the mingw libraries you're deploying with?
2. Could you make sure that those symbols are exactly as expected? You will need a tool to read the exported symbols (I think on windows it's "Dependency walker" or something like this). Post the names of __cxa_throw_bad_array_new_length, ***_throw_out_of_range_*** (stars could be any characters you meet) with their corresponding addresses here if you please.

Kind regards.

[panca]

This is a complete list of all binaries in SuperCollider:

icudt54.dll
icuin54.dll
icuuc54.dll
libfftw3f-3.dll
libgcc_s_dw2-1.dll
libreadline6.dll
libsndfile-1.dll
libstdc++-6.dll
libtermcap-0.dll
libwinpthread-1.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Multimedia.dll
Qt5MultimediaWidgets.dll
Qt5Network.dll
Qt5OpenGL.dll
Qt5Positioning.dll
Qt5PrintSupport.dll
Qt5Qml.dll
Qt5Quick.dll
Qt5Sensors.dll
Qt5Sql.dll
Qt5WebChannel.dll
Qt5WebKit.dll
Qt5WebKitWidgets.dll
Qt5Widgets.dll
scide.exe
sclang.exe
scsynth.exe

I would have said the mingw-libraries are
libstdc++-6.dll, libgcc_s_dw2-1.dll and libwinpthread-1.dll

as I stated in the first email. But then, there are also

icudt54.dll
icuin54.dll
icuuc54.dll

of which I am not sure, where they come from. But if they are available from the Qt tree, they must be from there, because by default all libraries found via system path com from the Qt tree first.

In our current default deployment everything available is taken from Qt (as I said).

Libsndfile and fftw come from the original providers (Mega-nerd and fftw.org).
Readline is actually from the MinGW tree, the 4.8.2 tree.

So it is only for this experiment that I used the three runtimes from the MinGW482 tree... Is it for those that you want me to look up the symbols?

Best
.r.

[kshegunov]

@panca said:

But then, there are also
icudt54.dll
icuin54.dll
icuuc54.dll
of which I am not sure, where they come from.

This is unicode support for Qt.

I would have said the mingw-libraries are
libstdc++-6.dll, libgcc_s_dw2-1.dll and libwinpthread-1.dll

I believe you are correct. pthread is not of interest for now, so let's forget it. I think you should start with libgcc_s_dw2-1.dll, as I suspect it as the prime culprit. However before starting to pull out symbols, try inspecting on which mingw libraries your application depends and on which Qt5Core.dll depends (again I think with "dependency walker" this should be possible) and please paste the results here.

PS.
On my system readelf -Ws /usr/lib/x86_64-linux-gnu/libstdc++.so.6 piped through a grep returns:

2051: 00000000000b4b50   264 FUNC    GLOBAL DEFAULT   13 _ZSt24__throw_out_of_range_fmtPKcz@@GLIBCXX_3.4.20
4158: 00000000000b4af0    82 FUNC    GLOBAL DEFAULT   13 _ZSt20__throw_out_of_rangePKc@@GLIBCXX_3.4

So we are looking for something similar.

ADDENDUM:
It should also be possible, when inspecting the mingw libraries your application and QtCore depend on, to see what are the unresolved symbols that are expected to be loaded from those libraries.

Kind regards.