[Interest] link error (and probably a dumb question)

[Thiago Macieira]

On Friday 18 September 2015 10:14:31 René J. V. Bertin wrote:
> 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?

Correct.

Though Jane Developer will know what's there because she installs libraries 
using the package manager.

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

If the default search path is /usr/lib/x86_64-linux-gnu, then the question is 
why you had to set PKG_CONFIG_PATH. If the system uses the Debian-style of 
multiarch, why do you have /usr/lib64?

> > 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)?

I said "begins with one of the paths". It won't search /usr/include/dbus-1.0 
unless you tell it. The difference is whether it passes -I/usr/include/dbus-1.0 
or -isystem /usr/include/dbus-1.0.

Qmake likes to know what the libraries in your LIBS are. The LIBS and 
LIBS_PRIVATE variable aren't dumbly copied into the Makefile. Qmake actually 
reorders them a little depending on what it finds in those libraries' .prl files 
and may insert dependencies too. In order to find the .prl files, it needs the 
full library search path. If the library isn't found after this, it assumes 
it's in a default search path it didn't know about and leaves it to the 
linker.

> > It will not strip any paths added to LIBS.
> 
> The question is more if it will add paths to the linker commands.

Since it will not strip, if you add them, they will be passed to the linker.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center