It wants to link with old library
Auto-assigned to maintainer kde@FreeBSD.org
That's right, I can confirm this happens. I'm fixing this for the upcoming 5.3.2 update.
A commit references this bug: Author: rakuco Date: Wed Nov 5 09:39:30 UTC 2014 New revision: 372179 URL: https://svnweb.freebsd.org/changeset/ports/372179 Log: Update Qt5 ports to 5.3.2. Proudly presented by the KDE on FreeBSD team, with several guest stars. This update took way longer than initially expected due to us previously accumulating assumptions and changes to Qt's build system that finally bit us back with the 5.3 release series, so we had to do a fair amount of cleanup. New ports: - comms/qt5-serialport: Qt functions to access serial ports, originally based on work by Fernando Apesteguia. [1] - devel/qt5-qdoc: Qt documentation generator, the Qt5 equivalent of devel/qt4-qdoc3. Originally worked on by Tobias Berner. It had already been half-split from devel/qt5-buildtools, we just needed to finish the work. Dead ports: - devel/qt5-qmldevtools: Merged into lang/qt5-qml. Minor changes: - devel/qt5: Add x11/qt5-x11extras and the new ports to the dependency list. - graphics/qt5-imageformats: The port now supports the JPEG2000, WEBP, Direct Draw Surface and ICNS formats. - multimedia/qt5-multimedia: The ALSA and PULSEAUDIO options are now mutually exclusive due to changes introduced in Qt 5.3.0 (the ALSA code is now a proper plugin that is only built if PulseAudio is not used). - x11/qt5-x11extras: Add USE_LDCONFIG since the port installs a shared library. The big changes: - bsd.qt.mk: Set QMAKESPEC instead of QMAKEPATH. [3] QMAKEPATH does much more than we want now that we call qmake from the top of ${WRKSRC}. qmake uses QMAKEPATH when evaluating the QMAKE_MKSPECS property, which is in turn used by qt_config.pri to load the .pri files in mkspecs/modules. In practice, this means that if people have an older Qt installation those files will be used and QT_CONFIG will have values such as "gui" even if one is building a port like textproc/qt5-xml, which passes -no-gui to the configure script. Consequently, unintended code paths may be enabled or the configuration step can just fail if the .pro files expect values that are not present in the system-wide, older .pri files. We avoid all those problems if we use QMAKESPEC, as qmake does not take its value into account when evaluating the QMAKE_MKSPECS property and will only parse the files in the mkspec's directory (mkspecs/freebsd-clang, for example, instead of all the files in mkspecs). - Stop explicitly passing ${LOCALBASE} to the compiler. [3] qmake's behavior has changed in Qt 5, and the paths set in QMAKE_INCDIR and QMAKE_LIBDIR in the mkspecs are passed before any others, such as the ones in the build directory themselves. In practice, this means that we end up with linker calls like this: c++ -o libfoo.so foo.o bar.o -L/usr/local/lib -L/wrkdir/build/lib -lQt5Gui -lQt5Core So if one already has Qt installed in the system, the older, already present version of the libraries in /usr/local/lib will be used instead of the newly-built ones in /wrkdir/build/lib. QTBUG-40825 discusses this behavior upstream, but there has been no agreement on a solution yet. For now, the solution adopted is to make the compiler and the linker aware of those paths but only try them last after all others, and this is achieved by setting the CPATH and LIBRARY_PATH environment variables when qmake is being used. In addition to setting them in CONFIGURE_ENV and MAKE_ENV, we also need to stop changing QMAKE_INCDIR and QMAKE_LIBDIR as well as filter those paths from the pkg-config calls qtbase's configure script makes. - Call qmake from the root of the ${WRKSRC}. In Qt 5.3, Qt's build infrastructure has undergone some changes that make our previous approach of calling qmake from the directories we want to build stop working. Things would break even more in Qt 5.4, in which qtbase's configure script does not accept the -process, -fully-process and -dont-process arguments anymore (it always behaves as if -process had been used). Bite the bullet and start calling qmake from ${WRKSRC}. The largest part of this change involves changing lines in Makefiles from WRKSRC_SUBDIR= foo/bar to BUILD_WRKSRC= ${WRKSRC}/foo/bar INSTALL_WRKSRC= ${WRKSRC}/foo/bar as well as adding patches to .pro files to avoid entering other subdirectories and removing post-configure targets that are not necessary anymore. Since qmake needs to be called from the top of ${WRKSRC} anyway, we can also simplify the configuration process for the qtbase ports a little. Looking at r10019 it is not clear why we started calling qmake in the pre-configure target in addition to the post-configure one (while also skipping it in do-configure), but we can now drop this call since letting configure behave as if -process had been passed means it will call qmake on its own and overwrite the files generated by the pre-configure call. We still need to call qmake in post-configure though, as the configure script does not pass -recursive when calling qmake and we need to be able to call make from any subdirectory when building. PR: 194762 [1] PR: 194566 # exp-run with base GCC and clang PR: 194088 [3] Changes: head/MOVED head/Mk/Uses/qmake.mk head/Mk/bsd.qt.mk head/comms/qt5-serialport/ head/comms/qt5-serialport/Makefile head/comms/qt5-serialport/pkg-plist head/databases/qt5-sql/Makefile head/databases/qt5-sqldrivers-odbc/Makefile head/databases/qt5-sqldrivers-sqlite2/Makefile head/databases/qt5-sqldrivers-sqlite3/Makefile head/devel/dbus-qt5/Makefile head/devel/qmake5/Makefile head/devel/qmake5/files/patch-mkspecs__common__clang-unix.conf head/devel/qmake5/files/patch-mkspecs__common__freebsd.conf head/devel/qmake5/files/patch-mkspecs__features__qt_functions.prf head/devel/qmake5/files/patch-mkspecs__freebsd-g++__qmake.conf head/devel/qmake5/files/patch-mkspecs__unsupported__freebsd-clang__qmake.conf head/devel/qmake5/pkg-plist head/devel/qt5/Makefile head/devel/qt5/distinfo head/devel/qt5/files/extrapatch-configure head/devel/qt5/files/extrapatch-libtool head/devel/qt5-assistant/Makefile head/devel/qt5-assistant/files/ head/devel/qt5-assistant/files/patch-src__src.pro head/devel/qt5-buildtools/Makefile head/devel/qt5-concurrent/Makefile head/devel/qt5-core/Makefile head/devel/qt5-core/files/ head/devel/qt5-core/pkg-plist head/devel/qt5-designer/Makefile head/devel/qt5-designer/files/ head/devel/qt5-designer/files/patch-src__src.pro head/devel/qt5-designer/pkg-plist head/devel/qt5-help/Makefile head/devel/qt5-help/files/ head/devel/qt5-help/files/patch-src__assistant__assistant.pro head/devel/qt5-help/files/patch-src__src.pro head/devel/qt5-help/pkg-plist head/devel/qt5-linguist/Makefile head/devel/qt5-linguist/files/ head/devel/qt5-linguist/files/patch-src__src.pro head/devel/qt5-linguisttools/Makefile head/devel/qt5-qdbus/Makefile head/devel/qt5-qdbusviewer/Makefile head/devel/qt5-qdbusviewer/files/ head/devel/qt5-qdbusviewer/files/patch-src__src.pro head/devel/qt5-qdoc/ head/devel/qt5-qdoc/Makefile head/devel/qt5-qmldevtools/ head/devel/qt5-script/Makefile head/devel/qt5-scripttools/Makefile head/devel/qt5-testlib/Makefile head/devel/qt5-testlib/pkg-plist head/devel/qt5-uitools/Makefile head/devel/qt5-uitools/files/ head/devel/qt5-uitools/files/patch-src__designer__src__src.pro head/devel/qt5-uitools/files/patch-src__src.pro head/devel/qtcreator/Makefile head/graphics/qt5-imageformats/Makefile head/graphics/qt5-imageformats/pkg-plist head/graphics/qt5-opengl/Makefile head/graphics/qt5-opengl/pkg-plist head/graphics/qt5-pixeltool/Makefile head/graphics/qt5-pixeltool/files/ head/graphics/qt5-pixeltool/files/patch-src__src.pro head/graphics/qt5-svg/Makefile head/graphics/qt5-svg/pkg-plist head/lang/qt5-qml/Makefile head/lang/qt5-qml/files/patch-git_b84f08c8 head/lang/qt5-qml/files/patch-jsruntime__qv4alloca_p.h head/lang/qt5-qml/files/patch-jsruntime__qv4engine.cpp head/lang/qt5-qml/files/patch-jsruntime__qv4mm.cpp head/lang/qt5-qml/files/patch-src__qml__jit__qv4assembler.cpp head/lang/qt5-qml/files/patch-src__src.pro head/lang/qt5-qml/pkg-plist head/multimedia/qt5-multimedia/Makefile head/multimedia/qt5-multimedia/pkg-plist head/net/qt5-network/Makefile head/net/qt5-network/pkg-plist head/print/qt5-printsupport/Makefile head/print/qt5-printsupport/pkg-plist head/textproc/clucene-qt5/Makefile head/textproc/clucene-qt5/files/patch-3rdparty__clucene__src__CLucene__search__FieldCacheImpl.cpp head/textproc/clucene-qt5/files/patch-src__assistant__assistant.pro head/textproc/clucene-qt5/files/patch-src__src.pro head/textproc/qt5-xml/Makefile head/textproc/qt5-xml/pkg-plist head/textproc/qt5-xmlpatterns/Makefile head/www/webkit-qt5/Makefile head/www/webkit-qt5/pkg-plist head/x11/qt5-qev/Makefile head/x11/qt5-x11extras/Makefile head/x11-toolkits/qt5-declarative/Makefile head/x11-toolkits/qt5-declarative/pkg-plist head/x11-toolkits/qt5-gui/Makefile head/x11-toolkits/qt5-gui/files/ head/x11-toolkits/qt5-gui/pkg-plist head/x11-toolkits/qt5-quick/Makefile head/x11-toolkits/qt5-quick/files/ head/x11-toolkits/qt5-quick/files/patch-src__src.pro head/x11-toolkits/qt5-quick/pkg-plist head/x11-toolkits/qt5-quickcontrols/Makefile head/x11-toolkits/qt5-quickcontrols/pkg-plist head/x11-toolkits/qt5-widgets/Makefile head/x11-toolkits/qt5-widgets/pkg-plist
Fixed at last! Thanks for staying with us.
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
A commit references this bug: Author: rakuco Date: Wed Dec 30 14:03:42 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