Thiago Macieira wrote: >> Indeed. Does it even need to link to QtDbus then? > > It links to QtBootstrapDBus.
That looks like an internal library which itself links to QtDBus, right? Some more thoughts how to work around this: - include only those required bits and pieces into QtBootstrapDBus rather than linking to QtDBus. If the connection-related code isn't required maybe the issue goes away when that code is removed. - do a bogus DBus connect (on ARM) or at least call QtDBusConnection::sessionBus() so there is something to clean up. The most "just" approach might be something like this: - find a way to deactivate the patch on ARM and wait until an ARM user complains about the issue it fixes. It could be just as unlikely that someone will run into the original issue on ARM as someone running into the build issue because of the patch. If we assume that there is now enough indication that the patch is required on Intel; with this approach you wouldn't be withholding it because of a potential issue on ARM. I'll try to figure out if the Debian QtCurve package maintainer(s) know whether they ever encountered the original crash-on-exit on ARM. Something else: > I think our ARM builds are little-endian, so endianness cannot be an issue. My bad, I extrapolated from my Mac/PPC experience that ARM was big-endian and learned only now it is bi-endian (a 1-letter difference with big consequences :)). R. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
