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
Curl Configuration Weirdness for libz.a
Hi Curl Team, I am building curl 8.2.1 for NonStop and received the following message: *** Warning: Trying to link with static lib archive /usr/coreutils/lib/libz.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. copying selected object files to avoid basename conflicts... ln: failed to create hard link '.libs/libcurl.lax/lt1-libz.a' => '/usr/coreutils/lib/libz.a': Cross-device link I supplied --with-zlib and the physical location of libz.a in the LDFLAGS to ensure that the libz.so is not used. Recent platform OS versions do have libz.so and libz.so.1.2.11 but older versions do not. I am building for the oldest supported OS version, which does not have libz at all, so linking with libz.a is required. Does this message actually prohibit the use of libz.a? I'm wondering whether modifying configure.ac might be needed to allow what I am trying to do - including making a copy of libz.a because of our file system structure that has a separate file set between /home and /usr for space reasons. Any advise? Thanks, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400) NonStop(2112884442) -- In real life, I talk too much. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html