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

[Alex Malyushytskyy]

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