RE: Curl Configuration Weirdness for libz.a
On Friday, September 1, 2023 2:39 PM, Dan Fandrich wrote: >On Fri, Sep 01, 2023 at 01:53:27PM -0400, rsbec...@nexbridge.com wrote: >> Slight change, please. The i386 should be x86 (and eventually x86_64 >> when I get the 64-bit builds working). > >i386 is a historical tag that basically means 32-bit Intel x86 architecture these days. >We should probably change them all to say x86 since there aren't very many actual >i386 binaries available in the world any longer. Good point. This platform is actually x86_64 chips but the two operating systems on it run in a mixed form of 32 and 64. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Fri, Sep 01, 2023 at 01:53:27PM -0400, rsbec...@nexbridge.com wrote: > Slight change, please. The i386 should be x86 (and eventually x86_64 when I > get the 64-bit builds working). i386 is a historical tag that basically means 32-bit Intel x86 architecture these days. We should probably change them all to say x86 since there aren't very many actual i386 binaries available in the world any longer. Dan -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
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
Re: Curl Configuration Weirdness for libz.a
On Thu, Aug 31, 2023 at 01:50:07PM -0400, rsbec...@nexbridge.com wrote: > On Thursday, August 31, 2023 1:41 PM, Dan Fandrich wrote: > >On Thu, Aug 31, 2023 at 11:09:58AM -0400, Jeffrey Walton via curl-library > wrote: > >> I think you should change strategies. You should use sed to change > >> references from -lz to libz.a (and friends). > > > >While that would work, devs shouldn't need to do this. curl's configure is > simply doing > >the wrong thing. I'll work on a patch. > > Thanks. https://github.com/curl/curl/pull/11778 I've tested that a zlib.pc file with a static library path now works fine. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Thu, Aug 31, 2023 at 1:41 PM Dan Fandrich via curl-library wrote: > > On Thu, Aug 31, 2023 at 11:09:58AM -0400, Jeffrey Walton via curl-library > wrote: > > I think you should change strategies. You should use sed to change > > references from -lz to libz.a (and friends). > > While that would work, devs shouldn't need to do this. curl's configure is > simply doing the wrong thing. I'll work on a patch. Another sharp edge... You can use the proper linker flags to link to the static archive rather than the shared object (like -l:libz.a*), and it will work fine on Linux and Solaris. But Apple linkers will still link to the shared object anyways. Even on iOS where shared object runtime linking was forbidden. In the Apple cases, I either (1) deleted the shared objects; or (2) used sed to call out the archive. [*] See the ld man page for -l:libz.a, https://linux.die.net/man/1/ld: -l namespec --library=namespec Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a. Jeff -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
On Thursday, August 31, 2023 1:41 PM, Dan Fandrich wrote: >On Thu, Aug 31, 2023 at 11:09:58AM -0400, Jeffrey Walton via curl-library wrote: >> I think you should change strategies. You should use sed to change >> references from -lz to libz.a (and friends). > >While that would work, devs shouldn't need to do this. curl's configure is simply doing >the wrong thing. I'll work on a patch. Thanks. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Thu, Aug 31, 2023 at 11:09:58AM -0400, Jeffrey Walton via curl-library wrote: > I think you should change strategies. You should use sed to change > references from -lz to libz.a (and friends). While that would work, devs shouldn't need to do this. curl's configure is simply doing the wrong thing. I'll work on a patch. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Thu, Aug 31, 2023 at 10:49 AM Randall via curl-library
wrote:
>
> On Wednesday, August 30, 2023 7:43 PM, Fandrich wrote:
> > [...]
> >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.
>
> When using a modified zlib.pc, the warning goes away, but -lz is added back
> by configure. The zlib.a is ignored, which is not the desired outcome. My
> zlib.pc as the Libs: line modified as follows (libz.a has to come first but
> does not take effect this way):
>
> Libs: ${libdir}/libz.a -L${libdir} -L${sharedlibdir}
>
> Instead of the original
>
> Libs: -L${libdir} -L${sharedlibdir} -lz
I think you should change strategies. You should use sed to change
references from -lz to libz.a (and friends).
What I have found from bootstrapping Wget on older systems that run
from non-standard locations [1]:
* use sed to change -l to point to the archive in configure [2]
* run configure
* use sed to change -l to point to the archive in the Makefiles [3]
When I say "point to the archive", I mean the absolute path to the
archive (though a relative path may work, if you are mindful of cwd
during command invocations).
After the configure/make/make check cycle, you will have an executable
that can run from anywhere without the need for RPATHs, RUNPATHs,
LD_PRELOAD and LD_LIBRARY_PATH tricks because there are no special
shared object dependencies. You will still depend on some shared
objects, but they are system shared objects like linux-vdso.so and
libc.so.
After I get Wget bootstrapped, I can build other programs, like cURL,
Git, OpenSSH, etc.
I bootstrap Wget instead of cURL because Wget only has two
dependencies - OpenSSL and libunistring. After I get a modern Wget on
a machine, I can build more complex programs like cURL or a fully
featured Wget.
Jeff
[1]
https://github.com/noloader/Build-Scripts/blob/master/bootstrap/bootstrap-wget.sh
[2]
https://github.com/noloader/Build-Scripts/blob/master/bootstrap/bootstrap-wget.sh#L274
[3]
https://github.com/noloader/Build-Scripts/blob/master/bootstrap/bootstrap-wget.sh#L310
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
On Wednesday, August 30, 2023 7:43 PM, 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.
When using a modified zlib.pc, the warning goes away, but -lz is added back
by configure. The zlib.a is ignored, which is not the desired outcome. My
zlib.pc as the Libs: line modified as follows (libz.a has to come first but
does not take effect this way):
Libs: ${libdir}/libz.a -L${libdir} -L${sharedlibdir}
Instead of the original
Libs: -L${libdir} -L${sharedlibdir} -lz
Using make ZLIB_LIBS=/usr/coreutils/lib/libz.a does not change the behaviour
from the original post. I'm not sure this is the confirmation you are
looking for.
>
>> 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.
Thanks
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
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.
Dan
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
On Wednesday, August 30, 2023 5:56 PM, Dan Fandrich wrote: >On Wed, Aug 30, 2023 at 05:03:34PM -0400, rsbec...@nexbridge.com wrote: >> Actually, there is no libtool on the platform, so upgrading will be >> difficult. No LIB, INCLUDES, or other compile-related environment variables. > >Then it will be using the built-in libtool, which should be fairly recent. >But, if there >are NonStop-specific changes that aren't upstream, you won't get them. >I think this is unlikely to be the issue here, though. > >> For the OpenSSL 3.0 build: >> CFLAGS="-c99" CPPFLAGS="-Wnowarn=2040 -D_XOPEN_SOURCE_EXTENDED=1 >> -WIEEE_float -I/usr/coreutils/include -I/usr/local-ssl3.0/openssl/include" >> LDFLAGS="/usr/coreutils/lib/libz.a -L/usr/coreutils/lib >> -L/usr/local-ssl3.0/lib" ./configure --prefix=/usr/local-ssl3.0 >> --with-ssl=/usr/local-ssl3.0 >> --with-ca-path=/usr/local-ssl3.0/ssl/certs >> --disable-pthreads --disable-threaded-resolver --enable-ipv6 >> --with-zlib=/usr/coreutils/lib/libz.a > >--with-zlib doesn't work this way. It's intended to receive the path to a zlib >installation >such as would be created after 'make install' when building zlib. >Specifically, there should be …/include/ and …/lib/ directories underneath >this path. >If there isn't such an install path on your system or it contains both libz.so >and libz.a, >it won't work. In that case, use --with-zlib and set PKG_CONFIG_PATH to a >location of >a zlib.pc file that only contains information on a static libz. Failing even >that, then >you'll likely have to resort to setting things like LIBS=/path/to/libz.a an >CPPFLAGS=- >I/path/to/zlib-include/ and hope the existing libz.so doesn't get in the way. My last hope, setting PKG_CONFIG_PATH=/usr/coreutils/lib/pkgconfig does not clear the issue, sadly. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
On Wednesday, August 30, 2023 5:56 PM, Dan Fandrich wrote:
>On Wed, Aug 30, 2023 at 05:03:34PM -0400, rsbec...@nexbridge.com wrote:
>> Actually, there is no libtool on the platform, so upgrading will be
>> difficult. No LIB, INCLUDES, or other compile-related environment variables.
>
>Then it will be using the built-in libtool, which should be fairly recent.
>But, if there
>are NonStop-specific changes that aren't upstream, you won't get them.
>I think this is unlikely to be the issue here, though.
>
>> For the OpenSSL 3.0 build:
>> CFLAGS="-c99" CPPFLAGS="-Wnowarn=2040 -D_XOPEN_SOURCE_EXTENDED=1
>> -WIEEE_float -I/usr/coreutils/include -I/usr/local-ssl3.0/openssl/include"
>> LDFLAGS="/usr/coreutils/lib/libz.a -L/usr/coreutils/lib
>> -L/usr/local-ssl3.0/lib" ./configure --prefix=/usr/local-ssl3.0
>> --with-ssl=/usr/local-ssl3.0
>> --with-ca-path=/usr/local-ssl3.0/ssl/certs
>> --disable-pthreads --disable-threaded-resolver --enable-ipv6
>> --with-zlib=/usr/coreutils/lib/libz.a
>
>--with-zlib doesn't work this way. It's intended to receive the path to a zlib
>installation
>such as would be created after 'make install' when building zlib.
>Specifically, there should be …/include/ and …/lib/ directories underneath
>this path.
>If there isn't such an install path on your system or it contains both libz.so
>and libz.a,
>it won't work. In that case, use --with-zlib and set PKG_CONFIG_PATH to a
>location of
>a zlib.pc file that only contains information on a static libz. Failing even
>that, then
>you'll likely have to resort to setting things like LIBS=/path/to/libz.a an
>CPPFLAGS=-
>I/path/to/zlib-include/ and hope the existing libz.so doesn't get in the way.
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}
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).
--Randall
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Wed, Aug 30, 2023 at 05:03:34PM -0400, rsbec...@nexbridge.com wrote: > Actually, there is no libtool on the platform, so upgrading will be > difficult. No LIB, INCLUDES, or other compile-related environment variables. Then it will be using the built-in libtool, which should be fairly recent. But, if there are NonStop-specific changes that aren't upstream, you won't get them. I think this is unlikely to be the issue here, though. > For the OpenSSL 3.0 build: > CFLAGS="-c99" CPPFLAGS="-Wnowarn=2040 -D_XOPEN_SOURCE_EXTENDED=1 > -WIEEE_float -I/usr/coreutils/include -I/usr/local-ssl3.0/openssl/include" > LDFLAGS="/usr/coreutils/lib/libz.a -L/usr/coreutils/lib > -L/usr/local-ssl3.0/lib" ./configure --prefix=/usr/local-ssl3.0 > --with-ssl=/usr/local-ssl3.0 --with-ca-path=/usr/local-ssl3.0/ssl/certs > --disable-pthreads --disable-threaded-resolver --enable-ipv6 > --with-zlib=/usr/coreutils/lib/libz.a --with-zlib doesn't work this way. It's intended to receive the path to a zlib installation such as would be created after 'make install' when building zlib. Specifically, there should be …/include/ and …/lib/ directories underneath this path. If there isn't such an install path on your system or it contains both libz.so and libz.a, it won't work. In that case, use --with-zlib and set PKG_CONFIG_PATH to a location of a zlib.pc file that only contains information on a static libz. Failing even that, then you'll likely have to resort to setting things like LIBS=/path/to/libz.a an CPPFLAGS=-I/path/to/zlib-include/ and hope the existing libz.so doesn't get in the way. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Curl Configuration Weirdness for libz.a
>-Original Message- >From: curl-library On Behalf Of Dan Fandrich >via curl-library >Sent: Wednesday, August 30, 2023 3:50 PM >To: curl-library@lists.haxx.se >Cc: Dan Fandrich >Subject: Re: Curl Configuration Weirdness for libz.a > >On Wed, Aug 30, 2023 at 03:27:34PM -0400, Randall via curl-library wrote: >> ln: failed to create hard link '.libs/libcurl.lax/lt1-libz.a' => >> '/usr/coreutils/lib/libz.a': Cross-device link > >This looks like a bad assumption on the part of libtool that a hard link is possible. I >don't know why it's try to do this in the first place. Have you tried updating libtool? >What configure options and environment variables are you giving when this happens? Actually, there is no libtool on the platform, so upgrading will be difficult. No LIB, INCLUDES, or other compile-related environment variables. For the OpenSSL 3.0 build: CFLAGS="-c99" CPPFLAGS="-Wnowarn=2040 -D_XOPEN_SOURCE_EXTENDED=1 -WIEEE_float -I/usr/coreutils/include -I/usr/local-ssl3.0/openssl/include" LDFLAGS="/usr/coreutils/lib/libz.a -L/usr/coreutils/lib -L/usr/local-ssl3.0/lib" ./configure --prefix=/usr/local-ssl3.0 --with-ssl=/usr/local-ssl3.0 --with-ca-path=/usr/local-ssl3.0/ssl/certs --disable-pthreads --disable-threaded-resolver --enable-ipv6 --with-zlib=/usr/coreutils/lib/libz.a For the OpenSSL 1.1.1 build: CFLAGS="-c99" CPPFLAGS="-Wnowarn=2040 -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/coreutils/include -I/usr/local-ssl1.1/include" LDFLAGS="/usr/coreutils/lib/libz.a -L/usr/local-ssl1.1/lib -L/usr/coreutils/lib -L/usr/local/lib" ./configure --prefix=/usr/local-ssl1.1 --with-ssl=/usr/local-ssl1.1 --with-ca-path=/usr/local-ssl1.1/ssl/certs --disable-pthreads --disable-threaded-resolver --enable-ipv6 --with-zlib=/usr/coreutils/lib/libz.a --with-openssl --prefix=/usr/local-ssl1.1 --Randall -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Curl Configuration Weirdness for libz.a
On Wed, Aug 30, 2023 at 03:27:34PM -0400, Randall via curl-library wrote: > ln: failed to create hard link '.libs/libcurl.lax/lt1-libz.a' => > '/usr/coreutils/lib/libz.a': Cross-device link This looks like a bad assumption on the part of libtool that a hard link is possible. I don't know why it's try to do this in the first place. Have you tried updating libtool? What configure options and environment variables are you giving when this happens? Dan -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
