[Interest] crashing when incompatible qt already exists on user's system

[Justin Karneges]

Hi folks,

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 
directly).

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.

Thanks,
Justin