https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195105
--- Comment #4 from Alexander Wolf <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ kde-freebsd mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
