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
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
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.