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? 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. > ... > > 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, 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)." > 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. _any_ tool that needs information that is hidden from it will of course not be as functional as it could be. > (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.) what? > -- > 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 -- <[EMAIL PROTECTED]> _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
