On Wed, 04 Oct 2006 10:40:37 +0200, Ralf Corsepius wrote: > In a nutshell, I mean "*.pc's are equally broken and not any better than > *.la's". > > They don't suffer from the same issues as *.la's but they also suffer > from defects, e.g. > * language specific compiler flags in *.pc > * compiler/compiler-version specific compiler flags in *.pc > * Incorrect hard-coded libs (-l<something>) > * Incorrect (Missing rsp. superfluous) deps (Requires: foo) > * pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS > * being manually written. > * being static (They denote a situation having being valid at one point > in time - There is no guarantee it still is, nor that they match ld.so's > configuration.). > ... In *many* cases they are much more better/useful, however, because with the pkg-config front-end (man pkg-config) they give very easy access to meta-information of installed packages in a similar way like custom "foo-config" scripts. This makes them an extremely popular choice whereas a big chunk of the "libtool stuff" is transparent to the package author. Additionally, .pc files in many cases are a strict build-requirement of the software to be built, as else the software set-up utility would not find installed libraries or be unable to use them. Unlike .la files. All you've come up with above is a list of potential bugs in .pc files without comparing it with a similarly extensive list of potential bugs in .la files. Sure, a big hindrance of .pc files is also that they suffer badly from the same dep-chain breakage, where "Requires" within a .pc file are not mirrored in the RPM package's "Requires" (neither automatically nor manually). As a result, -devel package users at the root of the dep-chain need to work around missing dependencies exactly as causes by incomplete .la packaging. A difference compared with .la files is that .la files add additional dependencies on absolute paths to other .la files, which makes it much more easy to break the chain, whereas .pc files just create links to other pkg names. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
