Em quarta-feira, 7 de dezembro de 2016, às 02:23:15 PST, Kevin Kofler escreveu: > > I think I had thought of that when I originally came up with the idea, but > > discarded it. I know I don't want it in developer builds for the same > > reason that QObjectPrivate's constructor does not complain about mixing Qt > > versions in developer builds (see 5bf67f5f41ab110eb41ab74f2a87e649735af435 > > for the rationale). But unlike the QObjectPrivate check, changing the ELF > > version according to Qt version would render a -developer-build library > > binary- incompatible with a non-developer-build user. > > > > I may have had other reasons, but I don't remember them now. > > > > So I think it's not a good idea to apply the SUSE patch as-is. > > But applying it downstream in distribution packages should be OK in any > case, shouldn't it? I don't think binary compatibility with upstream makes > sense for private symbols which are not even guaranteed to be compatible > between two upstream version.
I would rather distros not produce binary-incompatible patches to upstream Qt. This is such a patch. And I was actually affected by it: I wanted to backport an XRandR bugfix to libQt5XcbQpa, so I just built my own check out of qtbase on the tag + cherry- pick. But the lib wouldn't load because the ELF versions were different. I had to install qmake & qtbase development files from the distro so it would build and load. I'd like to come to an agreement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
