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. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
