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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
