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

[Justin Karneges]

Yes, explicitly setting the library paths seems like the safest way to address 
this.

I prefer being able to use the default plugin path during development though, 
so I'm using removeLibraryPath() to remove the default path, and doing it only 
if that path is not additionally specified in the QT_PLUGIN_PATH environment 
variable. Of course there are other ways to do this too, like removing the 
path only in release mode, etc.

On Monday, August 13, 2012 06:52:07 PM Alex Malyushytskyy wrote:
> Talking about Windows the only reliable solution is to supply all
> dependencies (at least not system) with your application.
> For example you can build dll with different compiler or version of
> the same compiler.
> You have to make sure that your application uses correct build of QT.
> On top of this, according to my experience,  you can't rely on Qt
> binary compatibility in the most cases when your application has
> subclasses with customized behavior..
> So make sure your application is provided with corrected Qt and plugin
> versions.
> 
> I personally use QCoreApplication::setLibraryPaths  at runtime for such
> purpose.
> 
> Regards,
>      Alex
> 
> On Mon, Aug 13, 2012 at 6:31 PM, Justin Karneges <justin at affinix.com> 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.
> > 
> > Thanks,
> > Justin
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest