[kde-freebsd] [Bug 199297] devel/qmake5: package may leak WRKSRC references in qt_targspec and qt_hostspec, breaking Qt5 ports

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199297

            Bug ID: 199297
           Summary: devel/qmake5: package may leak WRKSRC references in
                    qt_targspec and qt_hostspec, breaking Qt5 ports
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: kde at FreeBSD.org
          Reporter: danfe at FreeBSD.org
             Flags: maintainer-feedback?(kde at FreeBSD.org)
          Assignee: kde at FreeBSD.org

I normally build my ports with WRKDIRPREFIX=/usr/obj (central scratch-space for
building world, kernel, and ports).  On machines with lots of RAM, I make
/usr/obj a symlink to /tmp.  It turns out that this combination leads to
producing silently broken qt5-qmake package, which in turn breaks Qt5 consumer
ports.

The problem typically exhibits itself like this, when you start building some
software that is based on Qt5:

> CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message):
>   The imported target "Qt5::Core" references the file
> 
>      "/usr/local/lib/qt5//mkspecs//usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang"

Looks like CMake-related bits of Qt5 had become tainted somehow.  Doing "grep
-R /usr/local/lib/cmake/Qt5Core" shows only one bad file:

> /usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/lib/qt5//mkspecs//usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang")

This file is generated (while building devel/qt5-core) port from
src/corelib/Qt5CoreConfigExtrasMkspecDir.cmake.in:

> !!IF isEmpty(CMAKE_HOST_DATA_DIR_IS_ABSOLUTE)
> set(_qt5_corelib_extra_includes \"${_qt5Core_install_prefix}/$${CMAKE_HOST_DATA_DIR}/mkspecs/$${CMAKE_MKSPEC}\")
> !!ELSE
> set(_qt5_corelib_extra_includes \"$${CMAKE_HOST_DATA_DIR}mkspecs/$${CMAKE_MKSPEC}\")
> !!ENDIF

CMAKE_MKSPEC is set to QMAKE_XSPEC during the build; in turn, QMAKE_XSPEC value
is provided by qmake; let's see what it yields:

> /usr/local/lib/qt5/bin/qmake -query QMAKE_XSPEC
> /usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang

Running strings(1) over qmake binary indeed shows that bogus paths are embedded
in it:

> strings /usr/local/lib/qt5/bin/qmake | grep spec=
> qt_targspec=/usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang
> qt_hostspec=/usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang

Why does it happen?  Let's take a look at configure script:

> # the directory of this script is the "source tree"
> relpath=`dirname $0`
> relpath=`(cd "$relpath"; /bin/pwd)`
> ...
> shortxspec=`echo $XQMAKESPEC | sed "s,^${relpath}/mkspecs/,,"`
> shortspec=`echo $QMAKESPEC | sed "s,^${relpath}/mkspecs/,,"`
> ...
>    "qt_targspec=$shortxspec",
>    "qt_hostspec=$shortspec",

At this point it becomes fairly obvious.  Calling dirname(1) won't expand the
symlinked path (/usr/obj), but pwd(1) will!  So $relpath now starts with /tmp,
while $XQMAKESPEC and $QMAKESPEC are relative to /usr/obj; this confused sed(1)
and it cannot strip the prefix.

Quick and dirty fix is to patch devel/qmake5/Makefile like this:

> -QMAKESPEC=     ${WRKSRC}/mkspecs/freebsd-${QMAKE_COMPILER}
> +QMAKESPEC=     ${WRKSRC:tA}/mkspecs/freebsd-${QMAKE_COMPILER}

This trick won't work on systems with old make(1), e.g. FreeBSD 8.x.  The
problem, however, is not really about just qmake.  I suspect that there might
be more hidden bombs in our framework, not necessarily Qt5-related, that can
cause similar breakages.  I do not have a clean solution at hands for the
moment.

I'm not attaching any test cases or patches; I hope my analysis and description
are clear enough for our Qt/Mk maintainers, so they can work out the best
solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.