Release announcement:
https://blog.qt.io/blog/2019/02/01/qt-5-12-1-released/
Changelog:
https://wiki.qt.io/Qt_5.12.1_Change_Files
- A change was required to qt-dist.mk to always pass LOCALBASE to qmake,
as Qt5 has been installed to a prefix for some time now, there should
not be any harm in that, with respect to it picking up installed versions
of itself during build.
PR: 235622
Exp-run by: antoine
a symbol matches multiple clauses the last one takes precedence. If the
catch-all is last it captures everything. In the case of Qt5 libraries
this caused all symbols to have a Qt_5 label while some should have
Qt_5_PRIVATE_API. This only affects lld because GNU ld always gives the
catch-all lowest priority.
Older versions of Qt5Webengine exported some memory allocation symbols from
the bundled Chromium. Version 5.9 stopped exporting these [1] but the
symbols were kept as weak wrappers for the standard allocation functions to
maintain binary compatibility. [2][3] The problem is that the call to the
standard function in these weak wrappers is only resolved to the standard
function if there's a call to this standard function in other parts of
Qt5Webengine, because only then is there a non-weak symbol that takes
precedence over the weak one. If there's no such non-weak symbol the call
in the weak wrapper resolves to the weak wrapper itself creating an infinite
call loop that overflows the stack and causes a crash. Some of the
allocation functions are variants of C++ new and delete and it probably
depends on the compiler whether these variants are used in other parts of
Qt5Webengine.
Remove the weak wrappers (make them Linux specific). This isn't binary
compatible but we are already breaking that with the changes to the symbol
versions.
[1] 5c2cbfccf9
[2] 2ed5054e3a
[3] 009f5ebb4b
Bump all ports that depend on Qt5.
PR: 234070
Exp-run by: antoine
Approved by: kde (adridg)
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: →https://reviews.freebsd.org/D15540
The work was done by tcberner and myself, with thanks to antoine for the
exp-run.
Not a lot to report compared to other Qt5 updates:
* net/qt5-network is still broken with LibreSSL. I said this in a commit
message ages ago but it bears repeating: upstream is open to adding support
for LibreSSL, but someone needs to step up to maintain it upstream, otherwise
things will continue to be broken all the time.
* www/qt5-webengine is a huge monster that is terrible to update, just like
www/chromium itself is. We (kde@) have decided to keep using the 5.9 series
for the time being, as it should be compatible with the rest of Qt anyway. It
was updated to 5.9.5, the latest 5.9 release at the time of writing.
PR: 228213
For the qt5-* ports bsd.qt.mk sets EXTRACT_AFTER_ARGS, and
thereby does not get the normal default value of
--no-same-owner --no-same-permissions
passed when extracting. This lead to for example header files
being installed (i.e. copied), with permissions group write
permissions.
Manually append that to the bsd.qt.mk shenanigans (also do the
same in www/qt5-webchannel, which opts out of the bsd.qt.mk value)
PR: 227027
Reported by: grarpamp@gmail.com
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]
