[kde-freebsd] qmake5 fails to link

[Schaich, Alonso]

On Fri, 26 Jun 2015 10:02:55 -0300
Raphael Kubo da Costa <rakuco at FreeBSD.org> wrote:

> "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.

Go ahead.

However, the upgrade process traverses the package tree in dependency
order AFAIK, so at any point during the update, a qt-old version
library was either already overwritten by its qt-new counterpart, or
should not be referenced by the linker anyway, unless the ports
dependencies do not reflect the linker dependencies, or qmake is
messing up the library search paths for it's build/stage-dir libs with
the system path's ones.

Alonso
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20150626/2ad5e53c/attachment.sig>