[Interest] link error (and probably a dumb question)
René J. V. Bertin
rjvbertin at gmail.com
Fri Sep 18 10:14:31 CEST 2015
Thiago Macieira wrote:
>> I'd be curious to know if your pkg-config still strips the arch-specific
>> path out of its response.
>
> It does:
>
> $ env PKG_CONFIG_PATH=/usr/lib64/pkgconfig pkg-config --libs dbus-1
> -ldbus-1
Hmmm, and what's the nature of your /usr/lib64? Is it like /usr/lib/<arch>-
linux-gnu on debuntu systems in that it only holds the libraries for packages
that exist in multiple architectures and that Joe User is not supposed to
know/bother about its existence?
> The problem is that your pkg-config is apparently configured to understand
> something else (probably /usr/lib) as the system default path. So when you ask
> for it to search .pc files in /usr/lib64/pkgconfig (which installed libraries
> in /usr/lib64), then it thinks those paths are not system-default and prints
> them.
> Your pkg-config is buggy. Your distribution must fix them.
> This also shows that pkg-config is flawed for multiarch builds.
I'm inclined to agree with you, but am not so sure Canonical will share that
point of view (and quite sure about the "must fix" thing ;)). It might actually
be a feature that makes it possible to do 32bit builds on a 64bit system or
vice-versa. I never persisted in doing that but after first attempts failed and I
figured I could let Launchpad take care of it.
> There's some extra processing that it does. For paths added to INCLUDEPATH
> that begin with one of the paths in QMAKE_DEFAULT_INCDIRS, qmake will use the
> -isystem option instead of -I to pass to the compiler. It uses
> QMAKE_DEFAULT_LIBDIRS to *search* for libraries you passed in LIBS += without
> the corresponding -L flag, like for example:
>
> LIBS += -lm -lrt
Still, the compiler doesn't need -I or -isystem for paths that it adds to the
search list internally, and why would qmake search for libraries that are on
ld's default search path? To be able to abort if it thinks libraries are
unavailable rather than leaving that honour to the linker (all while presuming
it knows better than the linker)?
Way down the build road I'm now blocked in Source/WebKit on an error
"Project ERROR: x11 development package not found"
while evidently no such X11 packages had been missing until now. But that
appears to be more a problem that it calls the wrong pkg-config (i.e. the first in
the path, in /opt/local/bin) rather than the one I had configure use. (A
trace/verbose mode would be very helpful for this kind of situation!)
> It will not strip any paths added to LIBS.
The question is more if it will add paths to the linker commands.
R.
More information about the Interest
mailing list