[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg-config file for lzlib
Antonio Diaz Diaz
Re: pkg-config file for lzlib
Thu, 19 Jan 2023 19:49:09 +0100
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:184.108.40.206) Gecko/20110420 SeaMonkey/2.0.14
Niclas Rosenvik wrote:
I like to be able to look up lzlib via pkg-config, I searched the mailing
list and found that others want it too.
Maybe pkg-config is useful for libraries with non-standard dependencies, but
AFAICT pkg-config is 100% useless for lzlib. You may have noticed in my
previous answers that I don't like the idea of pkg-config and that I am
still waiting for someone to show me a real compilation problem solved by
the use of pkg-config:
"If I have understood correctly how pkg-config works, the .pc file must
be generated by the makefile at build time, and it contains fixed directory
names that prevent the library to be found if it is moved after instalation."
"Before even start thinking about this I need an example of a failed build
that is fixed by the inclusion of such a pc.in file (without requiring any
kind of autotools support)."
So here are patches that make this work.
Thank you. Nice patch. It certainly "makes this work" in the sense that it
creates a .pc file that can be used by pkg-config. But I still do not see
that it solves any real problem.
For example, your patch stores the .pc file in
"pkgconfigdir='$(libdir)/pkgconfig'", which makes me wonder why pkg-config
can find the .pc file but can't find the library just one directory above it
Storing a database of .pc files recording the locations of libraries adds
some problems, like finding the database itself, deciding what to do if
there is more than one database (in /usr/lib/pkgconfig and
/usr/local/lib/pkgconfig for example), or dealing with stale location data
(library moved or reinstalled elsewhere).
I have several versions of lzlib installed on my machine (in different
directories) to test plzip and tarlz, and I can't see how a .pc file could
help me find the one I want to use each time. Having to type
./configure lzlib_CFLAGS='-I <includedir>' lzlib_LIBS='-L <libdir> -llz'
./configure CPPFLAGS='-I <includedir>' LDFLAGS='-L <libdir>'
is not an improvement. (In fact it is wrong, because <includedir> belongs in
CPPFLAGS, not in CFLAGS).
BTW, lzlib provides macros and functions to check the version of the library
both at compile time and run time which are more reliable than the
configuration time test possible with pkg-config. (An application may be
dynamically linked at run time with a different version of lzlib than the
one it was compiled for, and this should not break the application as long
as the library used provides the functionality required by the application).
The install-pc target is not run by default, I leave it up to Antonio to
decide if the pkg-config file should be installed automatically or if
install-pc has to be run separately.
Installing the .pc file separately would be a bad idea because if one
forgets to do it the second time, the old .pc file may become out of sync
with the new installed library.
I think that adding a .pc file to lzlib would not solve any problems and may
create problems where there are currently none. If lzlib is installed in a
standard location, the compiler and the linker will find it. If lzlib is
installed in a non-standard location (or moved after installation),
pkg-config won't find it.
Moreover, there are discrepancies among pkg-config implementations. Which
makes me think that the concept itself of how pkg-config should work is not
(yet?) fully resolved. Maybe it is better to provide .pc files only for
those libraries that can take advantage of the services (?) provided by
In fact, after reading in the link below that "Current release versions of
pkg-config, on the other hand, build a database of all known pkg-config
files on the system before attempting to resolve dependencies", I'm moving
all the .pc files where pkg-config won't find them. I find it unacceptably
wasteful to read hundreds of files just to find out that you didn't need to
read them in the first place.
 See section "compatibility with pkg-config" at