[kde-freebsd] svn commit: r372491 - in head/x11-toolkits/qt5-quick: . files

Antoine Brodin antoine at FreeBSD.org
Thu Nov 13 07:12:11 UTC 2014

On Wed, Nov 12, 2014 at 12:34 PM, Raphael Kubo da Costa
<rakuco at freebsd.org> wrote:
> Author: rakuco
> Date: Wed Nov 12 11:34:38 2014
> New Revision: 372491
> URL: https://svnweb.freebsd.org/changeset/ports/372491
> QAT: https://qat.redports.org/buildarchive/r372491/
> Log:
>   Use a smarter strategy to avoid building src/qml and src/qmldevtools.
>   Simply patching src/src.pro to remove those directories from the build does
>   not work in all cases. If an older version of qt5-quick is installed, their
>   .pri files in mkspecs/modules will be picked up, and in the end when linking
>   programs such as tools/qmltestrunner something like this happens:
>     c++ [...] -Wl,-rpath-link,/usr/local/lib -o ../../bin/qmltestrunner
>               -L${WRKSRC}/lib -lQt5QuickTest [...]
>   The -rpath-link linker option will make ${LOCALBASE}/lib take precedence in
>   directory lookups, so when the newly-built libQt5QuickTest.so asks for
>   libQt5Quick.so in its DT_NEEDED section the older version installed in
>   ${LOCALBASE}/lib will be used instead of the one that has just been built.
>   If the new version has symbols the older one does not (Qt releases are
>   backwards, not forwards, compatible), the build will fail.
>   So instead of patching src/src.pro, we let the configuration process proceed
>   without any patching so that the local .pri files are created in
>   ${WRKSRC}/mkspecs and the Makefiles are created in a way that -rpath-link is
>   not passed to the linker anymore. We only need to symlink the existing
>   libraries built by lang/qt5-qml (this is similar to what we do with qtbase
>   ports to avoid rebuilding tools such as qmake and moc), and then change the
>   Makefiles in src/qml and src/qmldevtools so that nothing gets built.
>   This might even be a solution for other ports that got .pro patches in
>   r372179, since depending on which parts depend on which the same thing could
>   happen in the future.
>   I'm not bumping PORTREVISION because the resulting binaries will not change
>   and this only fixes the build where it was broken before.
>   PR:           194870


Somehow this fails to build with gcc from base now:




More information about the kde-freebsd mailing list