Installing the Qt 5.x libraties into /usr/lib causes issues when trying to develop for the Qt project and self-building Qt from git. The issue occurs when trying to develop bug fixes for Qt using the same minor release as the system installed Qt5 e.g. developing a fix for Qt 5.4.2 when Qt 5.4.0/.1 is installed. Or when trying to develop for Qt 5.5 when Qt 5.4 is installed. The cause of this is that some optional parts of Qt, e.g. the assimp scene loader from the upcoming Qt3D module depends upon libraries also in /usr/lib, libassimp in this case. When building such parts of Qt, the build system adds -L/usr/lib to the linker command line, rightly so. However, this causes the linker to attempt to link against the system Qt in preference to the Qt version currently being built. This results in unresolved symbols at best, or runtime errors due to mixing Qt libraries at worst. If the qt5-ebuild.eclass were to install the system Qt5 builds into named directories rather than directly into /usr/lib, this would avoid such issues. E.g. if qt5-build.eclass installed into /usr/qt-5.4/{include,lib,...}, /usr/qt-5.5/{include,lib,...} then the use of -L/usr/lib would not risk linking to the wrong Qt build. In addition it would be possible to have multiple minor versions of Qt installed side by side, e.g. /usr/qt-5.4 and /usr/qt-5.5. Reproducible: Always Steps to Reproduce: 1. Install Qt 5 and assimp from ebuilds 2. As a user try to build Qt5 from git on the 5.5 branch including the Qt3D module. 3. Watch for strange linker errors when linking the assimp scene parser plugin in Qt3D. Actual Results: Link fails with unresolved symbols from a few things that are new in libQt5Core.so in Qt5 but are not present in the system installed Qt 5.4. Expected Results: Linker should not be able to find libQt5*.so in /usr/lib. I'm the maintainer of the Qt3D module due to make an initial appearance in Qt 5.5. and I use Gentoo on all my machines so I would hate to have to change my workflow or OS or not be able to install a system level Qt5 (I'd like to take advantage of KDE Frameworks 5 at the system level).
(In reply to Sean Harmer from comment #0) I remember several large discussions about install locations and co-installability on the Qt-project development ML before 5.0 went gold, and I believe the conclusion was that the preferred path for libraries was /usr/lib (on linux). Indeed Fedora uses /usr/lib, and Ubuntu uses /usr/lib/x86_64-linux-gnu, which I suppose is the equivalent of /usr/lib in a multi-arch world. Have I misunderstood the recommendations? (or have they changed?) > The cause of this is that some optional parts of Qt, e.g. the assimp scene > loader from the upcoming Qt3D module depends upon libraries also in > /usr/lib, libassimp in this case. When building such parts of Qt, the build > system adds -L/usr/lib to the linker command line, rightly so. However, this > causes the linker to attempt to link against the system Qt in preference to > the Qt version currently being built. This results in unresolved symbols at > best, or runtime errors due to mixing Qt libraries at worst. > This can (should?) be fixed in the buildsystem/qmake itself by either: (a) not adding -L/usr/lib to the linker command line (it's a default path and will be searched as a fallback); or (b) passing -L/path/to/qt/build/tree before -L/usr/lib, thereby giving the Qt version currently being built a higher priority than the system-wide Qt installation.
Sean, any feedback?
Hi Davide, sorry for the delay I've been travelling with work and had very poor hotel wifi only. You make fair points. I agree this should be fixed upstream in the qmake/mkspecs build system. I'll see if I can figure out what needs to changed there. Feel free to mark this as won't fix or similar. Thanks for your time.
Thank you for your input!
