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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 30 Aug 2023 16:43:15 -0700
On Wed, Aug 30, 2023 at 06:08:38PM -0400, rsbecker_at_nexbridge.com 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, zlib.so, zlib.so.1.2.11 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 zlib.so.1.2.11 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 https://curl.se/download.html 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).
Done.
Dan
Date: Wed, 30 Aug 2023 16:43:15 -0700
On Wed, Aug 30, 2023 at 06:08:38PM -0400, rsbecker_at_nexbridge.com 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, zlib.so, zlib.so.1.2.11 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 zlib.so.1.2.11 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 https://curl.se/download.html 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).
Done.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-08-31