[Interest] crashing when incompatible qt already exists on user's system
justin at affinix.com
Tue Aug 14 03:31:10 CEST 2012
It appears that MinGW's C++ ABI is not reliable between releases. I don't know
how often this happens, but in any case I've witnessed the following issue:
- Build machine has C:\Qt\4.8.2, built using a recent MinGW compiler. This
machine builds my application.
- User's machine has C:\Qt\4.8.2, built using an older MinGW compiler (for
example, the binary package offered at qt.nokia.com). This installation of Qt
is not required to run the application, it merely happens to be there because
the user is also a Qt developer, perhaps working on other projects.
- When user runs the application generated by the build machine, the app
attempts to load plugins from C:\Qt\4.8.2\plugins on the user's machine. The
ABIs don't match, and the application crashes.
I can think of a few solutions:
1) Build machine should use a Qt path that is unlikely to exist on a machine
that the app is deployed to.
2) Remove C:\Qt\4.8.2\plugins from the plugin paths somehow (maybe this could
be done at runtime, with QCoreApplication::removeLibraryPath(), though I don't
know if this would have an effect on paths that are compiled into the lib
3) When building your own Qt, pass -buildkey to configure, so that Qt rejects
plugins that weren't built against the same Qt. This could work as long as the
signature check itself doesn't end up triggering an ABI-related crash. For
example, if nothing at the linking level could cause a crash, and the qtplugin
checks are pure C, then maybe this would be a safe choice.
I'm curious to know how others out there have mitigated this problem.
More information about the Interest