When I try compile Stellarium on my buildbot via Clang then Qt5 can't find GL/gl.h file. I got error like this: In file included from /usr/home/aw/achernar/achernar-FreeBSD/source/src/gui/StelGui.cpp:31: In file included from /usr/home/aw/achernar/achernar-FreeBSD/source/src/StelMainView.hpp:26: In file included from /usr/local/include/qt5/QtGui/QOpenGLContext:1: In file included from /usr/local/include/qt5/QtGui/qopenglcontext.h:62: /usr/local/include/qt5/QtGui/qopengl.h:110:12: fatal error: 'GL/gl.h' file not found # include <GL/gl.h> ^ 1 error generated. I'm tried build Stellarium on FreeBSD 10.1/amd64 with Qt 5.3.2 and 4 different compilers: Clang 3.4.1 (from base system) and 3.6.0 (from ports), GCC 5.0.0 and 4.9.2. This issue can't be reproduced with GCC. Detailed logs can be found here: http://gcc10.fsffrance.org:8010/waterfall
Fix synopsis and assign.
The issue can be fixed through set CPATH variable.
This was done intentionally when we upgraded Qt to 5.3.2. Basically, we were previously adding /usr/local/include and /usr/local/lib to QMAKE_INCDIR and QMAKE_LIBDIR, respectively. While this worked fine in Qt 4, there were changes in Qt 5 that made this cause problems when upgrading your Qt ports from, for example, 5.2 to 5.3, since sometimes the older, system-wide version would be linked instead of the new one being built, and symbols would be missing. There is QTBUG-40825 which I've filed upstream about that, and bug 194088 here about this. It is all taken care of automatically by the ports tree, since we set CPATH and LIBRARY_PATH in Uses/qmake.mk. People not using ports need to figure out what works best for them (LIBRARY_PATH, LDFLAGS and whatnot). In any case, I thought this wouldn't be a problem for CMake-based ports like Stellarium, since I'd expect them to look for GL headers and libraries and include them appropriately. Does Stellarium do that?
(In reply to Raphael Kubo da Costa from comment #3) > This was done intentionally when we upgraded Qt to 5.3.2. Basically, we were > previously adding /usr/local/include and /usr/local/lib to QMAKE_INCDIR and > QMAKE_LIBDIR, respectively. > > While this worked fine in Qt 4, there were changes in Qt 5 that made this > cause problems when upgrading your Qt ports from, for example, 5.2 to 5.3, > since sometimes the older, system-wide version would be linked instead of > the new one being built, and symbols would be missing. There is QTBUG-40825 > which I've filed upstream about that, and bug 194088 here about this. > > It is all taken care of automatically by the ports tree, since we set CPATH > and LIBRARY_PATH in Uses/qmake.mk. People not using ports need to figure out > what works best for them (LIBRARY_PATH, LDFLAGS and whatnot). > > In any case, I thought this wouldn't be a problem for CMake-based ports like > Stellarium, since I'd expect them to look for GL headers and libraries and > include them appropriately. Does Stellarium do that? I use FreeBSD as platform for automated building and testing of Stellarium via buildbot. Problem with finding GL/gl.h exists inside Qt 5 only with Clang. I can't reproduce this issue with GCC (both from ports), but she exists with clang-devel from ports. Well, seems I should check astro/stellarium port also.
(In reply to Raphael Kubo da Costa from comment #3) > In any case, I thought this wouldn't be a problem for CMake-based ports like > Stellarium, since I'd expect them to look for GL headers and libraries and > include them appropriately. Does Stellarium do that? projects may not use GL directly, in this case they don't bother to look for GL headers and libraries. But QtGui/qopengl.h refers to GL/gl.h, which is under /usr/local/include on FreeBSD, therefore this include path must be passed explicitly to compiler. I wonder why this problem reveals itself with clang only, base gcc should suffer from the same.
I have the same problem on 10.2-RELEASE with g++5. I am trying to build lablqt with ocaml-opam which simply uses g++ and pkg-config to determine the correct include and library search paths. It looks to me as if pkg-config --cflags for all of Qt5 is missing a -I/usr/local/include though the all include some specific sub directories. I also notice that pkg-config --libs-only-L is empty for most Qt5 modules, only two of them: Qt5Bootstrap.pc and Qt5QmlDevTools.pc return the correct value: "-L/usr/local/lib".
A commit references this bug: Author: rakuco Date: Mon Dec 28 18:51:42 UTC 2015 New revision: 404694 URL: https://svnweb.freebsd.org/changeset/ports/404694 Log: Make sure ${WRKSRC}/lib is passed before /usr/local/lib when linking. This is another shot at fixing the linkage problems that have plagued our users particularly when upgrading from Qt 5.x to 5.(x+1). Quick recap: in Qt5, qmake will by default pass QMAKE_LIBDIR to the linker before other directories such as ${WRKSRC}/lib, which is where the port's libraries are built. When a user is upgrading Qt, we can end up with the following linker line: c++ -o SomeBinary -lfoo1 -L/usr/local/lib -L${WRKSRC}/lib -lfoo2 -lfoo3 If libfoo2.so is being built by the port and an older version is currently installed on the system, /usr/local/lib/libfoo2.so will be picked up instead of the newly-built ${WRKSRC}/lib/libfoo2.so. At best things just work, at worst SomeBinary needs some new symbol that is not present in the old libfoo2.so and linking fails. Case in point: bug 198720. The previous approach, adopted when fixing bug 194088, was to stop setting QMAKE_{INC,LIB}DIR in the FreeBSD mkspecs and set the CPATH and LIBRARY_PATH environment variables in Uses/qmake.mk. This way we just did not pass -L/usr/local/lib to the linker at all and things mostly worked. However, people using Qt to build their own software without the ports tree were out of luck, as they would then need need to deal with passing /usr/local/{include,lib} to the compiler/linker themselves (bug 195105). Not only that, but if a dependency mentioned /usr/local/lib we would still have problems anyway (in bug 198720, the GStreamer pkg-config files contain -L/usr/local/lib, for example). We now solve the issue by setting the QMAKE_LIBDIR_FLAGS variable in .qmake.cache to ${WRKSRC}/lib instead. qmake appends the value of QMAKE_LIBDIR to QMAKE_LIBDIR_FLAGS, so we are always sure -L${WRKSRC}/lib will come before -L/usr/local/lib in the linker options. Moreover, qmake is smart enough to automatically call sed(1) and remove references to ${WRKSRC}/lib from .prl and .pc files when installing them. PR: 194088 PR: 195105 PR: 198720 MFH: 2015Q4 Changes: head/Mk/Uses/qmake.mk head/Mk/bsd.qt.mk head/devel/qmake5/Makefile head/devel/qmake5/files/patch-mkspecs__common__freebsd.conf
It took a very long time, but I think this is a good solution for both this bug and bug 194088. /usr/local/{include,lib} have been reinstated to the FreeBSD mkspec files, and we make sure that -L${WRKSRC}/lib is passed before anything else when building a port.
A commit references this bug: Author: rakuco Date: Wed Dec 30 14:03:43 UTC 2015 New revision: 404856 URL: https://svnweb.freebsd.org/changeset/ports/404856 Log: qmake5: Set QMAKE_{INC,LIB}DIR_OPENGL. Follow-up to r404694. When we stopped setting CPATH and LIBRARY_PATH, some Qt5-based ports (astro/stellarium, audio/musescore, audio/cantata, irc/quassel, deskutils/owncloudclient) broke because the QtGui headers end up bringing in GL/gl.h, but -I/usr/local/include was no longer being passed to the compiler. This is generally caused by QMAKE_{INC,LIB}DIR_OPENGL being empty, which leads to some parts of Qt5ConfigExtras.cmake.in being left out when being processed into Qt5ConfigExtras.cmake. Specifically, the bits of code that make the directories containing GL/gl.h and libGL.so a dependency of the Qt5::Gui CMake target were not present. Fix it by setting those two variables again like we also do in devel/qmake4. Most ports broken by r404694 are fixed by this change, but not all: * audio/cantata: Accidentally fixed by this change. Upstream includes the TagLib headers wrongly. `taglib-config --cflags' returns -I${LOCALBASE}/include/taglib, but the code references headers as <taglib/foo.h> instead of <foo.h>. * multimedia/obs-studio, textproc/sigil, x11/antimicro: Those remain broken, linker calls pass -lfoo instead of /path/to/libfoo.so, and they were only working because we were passing LIBRARY_PATH to the linker before. They need to be fixed separately. Thanks to antoine@ for the fallout heads-up. PR: 194088 PR: 195105 PR: 198720 MFH: 2015Q4 Changes: head/devel/qmake5/Makefile head/devel/qmake5/files/patch-mkspecs__common__freebsd.conf head/x11-toolkits/qt5-gui/Makefile