On Monday, August 13, 2012 07:33:53 PM Bob Hood wrote: > On 8/13/2012 7:31 PM, Justin Karneges wrote: > > 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. > > What about using a qt.conf file with: > > [Paths] > Prefix = . > > with the plugins/ folder containing plug-ins known to work with the > application in the same folder as the application, or: > > [Paths] > Plugins = <path_to_plugins> > > and a plugins/ folder containing the same content pointed to by that path.
Ah, yes, qt.conf. This changes the default path, correct? Since I only want to remove the default path, but leave everything else alone (such as paths from the QT_PLUGIN_PATH env var), using qt.conf seems cleaner than a conditional removeLibraryPath(). Justin _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
