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.) ... The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt. As opposed to: [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY] The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. [27] The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy for packages that are installed outside of the local system's software management infrastructure. (/usr/local is the default install prefix for the autotools to gently enforce this.) The /opt hierarchy, on the other hand, may be more widely used by third-party software that does integrate with the local system's software management infrastructure, but is not a part of the local system's core installation. The /opt hierarchy may also be used by operating system distributors who *want* to isolate each package, and 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 is no requirement that software installed into /opt make its presence known (in well-known locations). Hence, to be reliable, PKGConfig would either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers manually specify from which install prefix to pull information. Either way, PKGConfig's reliable usefulness is reduced to being something like a means of storing CFLAGS and CPPFLAGS preferences for specific instances of a software package; it can not be relied upon in all cases as helping manage systems with multiple versions of a package installed. (That is, in a case where a .pc file might be installed in a well-known location without the library and header files being installed in well-known locations, an .la file could be similarly installed separately to provide access to the same kind of information, just lacking the header file component.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ There is a lot of food in a supermarket, too, but a supermarket isn't the best place to hold a dinner party. -- Christopher Faylor _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
