[kde-freebsd] qmake5 fails to link

[Raphael Kubo da Costa]

"Schaich, Alonso" <alonsoschaich at fastmail.fm> writes:

> Hi
>
> Over here, qt5's qmake fails to link even the trival qt5 projects
> (attached), when invoked via
>
> #> /usr/local/lib/qt5/bin/qmake -makefile && make
>
> as it doesn't add /usr/local/lib to the library path used by the linker
> on a FreeBSD-10 system where qmakespec defaults to freebsd-clang.
>
> I traced this to r10442 of area51 which removed the QMAKE_LIBDIR
> extension from the freebsd qmakespec - inverting the
> devel/qmake5/files/patch-mkspecs__common__freebsd.conf part of r10442
> fixes the linker invokation.
>
> While a "fix" would be easy, rather than manual qmake invokation
> being broken on FreeBSD-10/WITH_CLANG_IS_CC for almost half a year
> unnoticed, I rather like to think that I'm invoking qmake poorly.
>
> What's the "right" way of invoking qmake5?

Sorry for not answering this earlier.

r10442 is just the merge commit. The actual change was done with a
fairly long explanation in r10435: the point is that if we pass
-L/usr/local/lib like that we break the upgrade process to anyone
building the ports from sources, as the build process often ends up
linking against, say, your installed Qt 5.3 when you are trying to build
Qt 5.4. See ports/194088 as well as QTBUG-40825 for more information.

And it hasn't gone really unnotice: ports/195105 is precisely abot this
sort of issue, where manual invocations of qmake5 break when people do
not explicitly set LIBDIR at least.

The problem is that upstream hasn't really welcomed any efforts to fix
the situation, and fixing 194088 is more important than fixing 195105,
so until we figure out a solution to both I'd like to revert your
r10691.