QtSLiM Runtime/Build Qt5 version mismatch

[bcar...@mtroyal.ca]

Hi,

After a package update to Qt5, QtSLiM will no longer run and must be rebuilt.

The error I get is:

Run-time Qt version 5.14.2 does not match compile-time Qt version 5.13.2.

Thanks,

Bryce.

[Ben Haller]

Hi Bryce.  This is unsurprising, right?  You built QtSLiM against a particular version of Qt, and then you changed the version of Qt, so you then need to rebuild QtSLiM.  The error is presumably being generated by either the linker/loader or by Qt itself; QtSLiM certainly doesn't have any smarts with respect to this issue.

Cheers,

-B.

Benjamin C. Haller

Messer Lab

Cornell University

[bcar...@mtroyal.ca]

Hi Ben,

Does SLiMgui do any static linking against Qt or Qt Plugins?

From what I have read about Qt, a user should be able to use a higher Qt runtime version than the compile time version. I'm a little confused about it, though. Just wondering.

Regards,

Bryce.

[Ben Haller]

Hi Bryce.  Honestly, this is one of those things that I don't understand very well either.  :->  It also depends on the platform, and might also depend on how the software gets built (Xcode vs. cmake vs. qmake).

The SLiMgui for macOS that gets installed by the macOS installer has had the build version of Qt incorporated into the app bundle as a private framework, against which the app then links.  This is described in detail at https://doc.qt.io/qt-5/macos-deployment.html, but honestly the details of how it works are way above my pay grade.  :->  In practice, though, it means that with the installer version of SLiMgui on macOS, the app is self-contained and does not depend upon any external Qt installation.

On Linux I believe things are quite different, but as you know I'm not very knowledgeable about Linux.  The corresponding Qt doc page for Linux is at https://doc.qt.io/qt-5/linux-deployment.html, which might prove useful to you.  I wrote before (back in 2020! :->) that I didn't know where that "Run-time Qt version 5.14.2 does not match compile-time Qt version 5.13.2" message was coming from, but I don't know why I wrote that; I was apparently confused.  :->  That message is generated from line 198 of QtSLiM's main.cpp:

// Check that the run-time Qt version matches the compile-time Qt version

if (strcmp(qVersion(), QT_VERSION_STR) != 0)

{

    std::cout << "Run-time Qt version " << qVersion() << " does not match compile-time Qt version " << QT_VERSION_STR << std::endl;

    exit(EXIT_FAILURE);

}

It looks like I added that in May of 2020 (https://github.com/MesserLab/SLiM/commit/c51a681e1468b9f29a4c77e462a24058a9056983).  I no longer recall the impetus for adding the check, but in general it seems like a good idea to me.  Rebuilding SLiMgui is quite easy, so I don't see any very compelling reason to run SLiMgui against a different version of Qt than it was built against.  Yes, it might *usually* work; but if it doesn't work, then you'll probably crash, and even if it *appears* to work it might be malfunctioning in subtle ways, and debugging such issues would be a nightmare when they did arise.  Better to just do a version check to make sure that the two match, it seems to me, to avoid that whole can of worms.  If we had the resources to do thorough QA testing – build version X, runtime version Y, does it work? – for every possible combination of versions then perhaps we could make the check smarter, but of course we do not have those resources.

To underline why it's potentially important for version numbers to match up, note that in quite a few places in SLiMgui's code there are checks like this:

#if (QT_VERSION < QT_VERSION_CHECK(5, 11, 0))

...

#else

...

#endif

These are checking the *build* version of Qt, and doing different things when building against different versions.  This can be because an old API got deprecated, or because new/better API that I would prefer to use got added, or to avoid a bug in an old Qt version by using a workaround, etc.  So the built code is built on the assumption of a particular version of Qt.  If it were to run against a different version of Qt, all of these spots in the code would then be potential failure points.

Anyhow, I guess this means that SLiMgui on Linux is being dynamically linked, by definition – if it were statically linked then it wouldn't be possible for the runtime Qt version to be different from the build-time Qt version, I suppose.  I'm not sure about much of this; I'm actually quite ignorant about the details of how linkers work, especially on Linux!  I'm also not sure how exactly this gets controlled by the various makefiles in use (Xcode, cmake, qmake).  The CMakeLists.txt for SLiM has this, for non-Windows platforms:

            target_link_libraries( ${TARGET_NAME} PUBLIC Qt5::Widgets Qt5::Core Qt5::Gui OpenGL::GL gsl tables eidos_zlib )

I'm not sure whether/how that specifies that the link is dynamic vs. static.  It is even less clear to me how the link type gets specified in the QtSLiM.pro file that qmake uses.  Sorry I'm so clueless; linking is just not a level of the development process that I have ever been comfortable working at, since on macOS it all gets handled by the Xcode IDE and there is a standard macOS way ("frameworks") that linkage gets handled.  As a result, I've just never gotten into these particular weeds :->.  Perhaps someone who knows more about this stuff can provide a better answer!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

[Sean Ryan]

Hi Ben,

I ran into this issue as well when installing on Windows with the installer (Qt version 5.15.3 does not match compile-time Qt version 5.15.2). What is the best remedy for this? Do I need to build from source or is there another fix for the installer version?

Thanks!

Sean

[Ben Haller]

Hi Sean!

For this to happen, you must have two different versions of Qt installed on your machine, I suppose: the one SLiM is built against and the one it runs against.  (Maybe, depending on how the installer on Windows works, the one SLiM is built against is not technically on your machine, but on some other machine where the installer was built, but that doesn't change the basic argument here.)  The simplest solution is probably therefore (1) delete all installed versions of Qt from the machine completely, and then (2) run the installer again.  Then there will be only one version of Qt present, and so the dynamic linker presumably won't be able to screw up.  It seems like a bug in the linker to me, in some sense; if you build against a given version, you ought to get linked to that same version at runtime, I would think.  To do otherwise is to invite all kinds of nasty bugs (which is why SLiMgui checks for such a mismatch and errors out).  I don't know whether building from source would be likely to resolve the problem or not, but it's very easy to try, so you might as well give it a whirl, if you don't want to delete all the Qt installs from your machine for some reason.  The other possible fix is a command-line option or environment setting of some kind that would tell SLiMgui, when the linker is loading it into memory, the filesystem path of the version of Qt that it ought to use; if you tell the system that explicitly, then it ought to do what you tell it to do.  I don't know how to do that on Windows, but a little Google-fu might pay off.  If you figure out a solution, please do report back on this thread.  Otherwise, perhaps someone more knowledgeable about Windows will chime in – Bryce or Russell or Bernard, perhaps.  Good luck!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

[Roslyn Nolan]

Hi,

I'm also having this problem on a new windows machine (Qt version 5.15.3 does not match compile-time Qt version 5.15.2), interestingly I installed slim using msys last week on a different machine with no issues (both machines have the same software, they are university machines, so neither have existing Qt stuff on them to clash). 

I wonder if there is something funny going on with the Qt version with msys because on the machine from last week the Qt dlls are all 5.15.2 and this week they are all 5.15.3. It seems like perhaps msys have updated the Qt version in the last week (which would be right according to https://raymii.org/s/blog/Qt_5.15.3_OpenSource_released.html) and now it seems to be causing problems with the building of the slim GUI.

I emailed the msys guys and the only response I got was 'It's slim-simulator that should be rebuilt against Qt 5.15.3' ...but I am building it with 5.15.3 from msys?!

This doesn't solve the problem but hopefully this might help us piece together what's going on with the windows gui install...

Cheers

Roslyn 

[Roslyn Nolan]

Hi again,

It just occurred to me that the msys installation approach isn't actually building the gui (?) so does that mean the gui has been pre-built by @Ben Haller (?) using Qt 5.15.2 and uploaded to msys and now msys have updated to 5.15.3 so they are no longer compatible when downloaded together? I noticed in my mingw64 bin the slimGUI.exe has a date stamp of 15.02.22, so can't have been built by me today and was built prior to the open source release of 5.15.3.

I'm of course still able to run slim through the command line with script files however I was hoping to show SLiM using the GUI to my lab group next week, hence my interest in resolving the windows GUI issue.

Cheers!

Roslyn

--
SLiM forward genetic simulation: http://messerlab.org/slim/
---
You received this message because you are subscribed to a topic in the Google Groups "slim-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/slim-discuss/wH2ocM3MmVE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to slim-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/slim-discuss/e5522e83-0dae-4beb-8e00-b3537be90264n%40googlegroups.com.

[Sean Ryan]

Thanks Ben,

Perhaps an unnecessary level of brute force, but I removed msys altogether and reinstalled, however I did not update the base packages (i.e,. "pacman -Syu") before installing slim. This worked. I then updated the base packages after installing slim.

For context, last night I tried reinstalling msys, updating the base packages (as recommended) and then slim but I still got the same error. So bypassing the update *seemed* to work. With an n = 1 this may be more witchcraft than science. I don't believe I did anything different in those two different approaches than what I describe but who knows. =)

@Rosalyn I would be curious to know if this works for you.

Sean

[Roslyn Nolan]

Hi,

An update as of today from the mysy folks, they have fixed the slim simulator package Qt issue, see https://github.com/msys2/MINGW-packages/pull/10955,  if you follow the following instructions on the thread I opened on the msys git site https://github.com/msys2/MINGW-packages/issues/10952 it should all work fine! 

Cheers

Roslyn 

[Ben Haller]

Hi Roslyn, Sean, and others.  Roslyn, that news sounds great, thanks for letting us all know.  Hopefully their fix is good, and this issue just goes away – that would be a big relief, since I had no idea what to do about it.  :->

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University