On Wednesday, August 30, 2023 7:43 PM, Dan Fandrich wrote:
>On Wed, Aug 30, 2023 at 06:08:38PM -0400, rsbec...@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.Slight change, please. The i386 should be x86 (and eventually x86_64 when I get the 64-bit builds working). Thanks, Randall -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
