[Interest] link error (and probably a dumb question)
René J. V. Bertin
rjvbertin at gmail.com
Fri Sep 18 20:34:56 CEST 2015
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
> 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
* 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.
More information about the Interest