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

[René J. V. Bertin]

Thiago Macieira wrote:

> No. But note I am talking about a different persona. The user who doesn't
> develop will not care where the software is installed and about libraries. The
> developer, on the other hand, will care what libraries are and that they get
> installed properly.

Of course I had noticed that. But I'm not sure we're talking about an average 
developer (Joe User average kind of average) who cares exactly where a 
distribution puts libraries, rather than only about a reliable way to get them 
installed and then find them in whatever build system s/he is using.
 
> /opt/local is not a system path.

No, but if you configure pkg-config to be installed under that prefix, it will look 
under /opt/local and not under /usr/lib.

> The question is why you have dbus and glib in a non-standard path in your
> system in the first place.

Did I say I did? They're in the standard locations for an Ubuntu system.

> Not really. It sounds to me that the fault lies with you by installing a badly
> configured pkg-config in /opt/local/bin and by having that in $PATH ahead of
> the standard pkg-config.

It's not badly configured, it's configured with --prefix=/opt/local , see above.

Since it wasn't clear: I'm reusing the platform-agnostic parts of MacPorts build 
and packaging scripts to install certain things in a parallel prefix. I'd use 
pkgsrc or Gentoo Prefix, but the latter doesn't work on Ubuntu and the former 
would require building all dependencies from scratch (and that would include a 
pkgconfig configured just like mine from /opt/local/bin). The concept of those 
systems is to be as self-contained as possible; I'm using my (by now) intimate 
knowledge of MacPorts to allow packages to depend on system libraries where I 
decide that's opportunistic.

> Then please stop talking about paths you don't have. You're the one who
> brought /usr/lib64 up. You're confusing me.

OK, but I was under the impression that it was you who mentioned that path first.

>> Hmmm, sounds like it's still a good idea to remove the multiarch paths from
>> DEFAULT_LIBDIRS for a Qt to be installed in a prefix like /opt/local .
>> Presuming only Qt installs .prl files, there best be no confusion between
>> versions.
> 
> Does your linker search there by default? If so, why would you remove?

there = where? Now I'm confused :)

* I understand that qmake searches in /usr/lib/x86_64-linux-gnu if it's in 
DEFAULT_LIBS and then might do clever things with information obtained from the 
.prl files in that directory
* That could lead to unforeseen (and maybe inexplicable) effects if you want to 
use the libs and corresponding .prl files from another library (/opt/local/lib) 
=> does qmake somehow prioritise prls for the same library coming from different 
directories?
* as far as I can deduce and as long as those locations aren't given explicitly 
via -L, the Ubuntu ld searches in the multiarch directories when it hasn't found 
a -l lib otherwise.

R.