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


More information about the Interest mailing list