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: k...@freebsd.org
Reporter: da...@freebsd.org
Flags: maintainer-feedback?(k...@freebsd.org)
Assignee: k...@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.
_______________________________________________
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
