Hi Jacob,
Jacob Meuser wrote:
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote:
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig ) You seem to be a victim of a package install where every package has ) used its own unique installation prefix. It seems to me that most ) systems use just one or two installation prefixes.
[http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] /opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.
...
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.
(It may be arguable that having to manually specify paths to find .pc files to pkg-config is not functioning "normally"--at least not within the stated goals of PKGConfig's developers--as Gary pointed out.)
huh? so pkg-config is supposed to look in _every_ directory to find .pc files?
Nope. Just the ones required to let me link with the library I specify.
besides the second part of what you quoted is what should have happened on Gary's system, so instead of all the separate paths under /opt, there would have simply been /opt/lib/pkgconfig.
But the point of splitting things into separate directories is so that I can have parallel installs of, say, libpng-1.2.4 and libpng-1.2.7, and link them against, say, zlib-1.1.4 and zlib-1.2.2 respectively. You can't do that with a shared pkgconfig directory. And without a lot of manual intervention, pkg-config actually makes it harder to do that than just looking up the dependencies by hand. :-(
yes, because they "*want* to isolate each package", but the administrator failed to "either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management)."
There shouldn't be any need to do this. All the information was already known when the .pc file was made, but it wasn't saved.
_any_ tool that needs information that is hidden from it will of course not be as functional as it could be.
pkg-config could either get it from ldd at link time, or at install time from configure. Or it could co-operate with libtool...
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
