-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LDFLAGS passed too late making libs linked incorrectly, e.g. OpenSSL #14893
Comments
When configure runs, does it detect the correct OpenSSL version/prefix? If so, doesn't the build use the correct include files etc? If so, doesn't the resulting build use OpenSSL 3 APIs that is not available in OpenSSL v1, so how can it even use the wrong library? |
Here is the relevant output:
and I can see in
See at I also did check |
Rings some bells from the the old Solaris issue where linker flags are positional, but libtool isn't aware of it. Ref #13317. (A previous solution was to repeat |
That's the one I found as well. Checked the manpage of |
@vszakats Picking up your comment: #13317 (comment) The manpage of
From the loader manpage:
|
What's curious is that libtool isn't aware of this. Also in general it's a good practice to have LDFLAGS precede LIBS. I wonder why it isn't like that by default. Or if there is any knob to turn, to make it work like that? |
Feels like an issue someone building on such a platform needs to work on since trying to address this blindly is likely to get it (subtly) wrong and make it into a very slow and tedious process. |
I did this
Compiling latest curl on HP-UX and linking against not the system provided OpenSSL (which is on the default loader/linker path), but against a self-compiled newer version:
call:
Summary:
Result:
I have now both OpenSSL version in the runtime path because in
lib/Makefile.in libcurl_la_LINK
andsrc/Makefile.in libcurltool_la_LINK
haveLDFLAGS
afterLIBS
(LIBCURL_PC_LIBS_PRIVATE
) the linker finds the default path first forlibssl.so
.verbose:
I cannot tell whether any of the recent changes should be reverted or not, but that comes a surprise because I explicitly pass
CPPFLAGS
andLDFLAGS
to have autoconf to find the headers and libraries in the right place and not in default locations.#12312 looks like a workaround to make it work again:
Well, using
CURL_LDFLAGS_{LIB,BIN}
is not straight forward at all because it is not documented, nor does one know that it has to be passed tomake
instead of to./configure
I expected the following
LDFAGS
passed beforeLIBS
so the linker can pick up the right library to build upRPATH
.There has been some changes in terms of linking in the past few months looking at the closed issues and PRs.
curl/libcurl version
curl --version
curl 8.10.0 (ia64-hp-hpux11.31) libcurl/8.10.0 OpenSSL/3.0.15 zlib/1.3.1
Release-Date: 2024-09-11
Protocols: file http https ipfs ipns smtp smtps
Features: GSS-API HSTS HTTPS-proxy IPv6 Kerberos Largefile libz SPNEGO SSL UnixSockets
operating system
HP-UX deblndw0 B.11.31 U ia64 HP-UX
aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]
/opt/ports/bin/openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)
/usr/bin/openssl version
OpenSSL 1.1.1w 11 Sep 2023
The text was updated successfully, but these errors were encountered: