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

[Justin Karneges]

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