curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Curl Configuration Weirdness for libz.a

From: Dan Fandrich via curl-library <>
Date: Wed, 30 Aug 2023 16:43:15 -0700

On Wed, Aug 30, 2023 at 06:08:38PM -0400, wrote:
> Unfortunately, the packaging team for the platform did not help on this one. zlib.h is in the /usr/coreutils/include directory, the zlib.a,, are in /usr/coreutils/lib (which collide). The zlib.pc file does not help particularly:
> prefix=/usr/coreutils
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> sharedlibdir=${libdir}
> includedir=${prefix}/include
> Name: zlib
> Description: zlib compression library
> Version: 1.2.11
> Requires:
> Libs: -L${libdir} -L${sharedlibdir} -lz
> Cflags: -I${includedir}

You could try hacking a copy of zlib.pc and replace "-lz" with "/usr/coreutils/lib/libz.a"
then force configure to use it with PKG_CONFIG_PATH=/path/to/hacked/file, but
I'm pretty sure that even that won't completely get rid of the use of -lz.
Running 'make ZLIB_LIBS=' after the configure should get rid of one lingering
instance of it but there's another one that will still show up.

If you can confirm that behaviour, then IMHO, configure should be changed to stop doing
that. If pkg-config has successfully found zlib, then configure shouldn't be
adding its own libraries and link flags to what pkg-config says is correct.

> which really will force being selected, and I cannot use that for packaging curl for the general population as that DLL is only available on the minority of machines. (On that subject, can you change the ref on from my name to ITUGLIB - which is the volunteer org who would take over if I get hit by a bus - but I'm glad we're listed there and it is otherwise correct).


Received on 2023-08-31