Skip to content
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

Configure fails to identify OpenSSL 3.0.0 headers #7606

Closed
rsbeckerca opened this issue Aug 21, 2021 · 16 comments
Closed

Configure fails to identify OpenSSL 3.0.0 headers #7606

rsbeckerca opened this issue Aug 21, 2021 · 16 comments
Labels

Comments

@rsbeckerca
Copy link

@rsbeckerca rsbeckerca commented Aug 21, 2021

When configuring with OpenSSL 3.0.0 beta2, configure is unable to recognize the OpenSSL version. The library version is also incorrectly identified. 1.1.1 is not in the library path nor in /usr/local/lib. 3.0.0 is the version reported by the library in /usr/local-ssl3.0/lib.

I did this

./configure with OpenSSL 3.0.0
... snip ...
configure: Added /usr/local-ssl3.0/lib to CURL_LIBRARY_PATH
checking for OpenSSL headers version... unknown - ( (3<<28) |(0<<20) |(0<<4) |0x0L )
checking for OpenSSL library version... 1.1.1
checking for OpenSSL headers and library versions matching... fail
configure: WARNING: Can not compare OpenSSL headers and library versions.

I expected the following

configure: Added /usr/local-ssl3.0/lib to CURL_LIBRARY_PATH
checking for OpenSSL headers version... 3.0.0
checking for OpenSSL headers and library versions matching... matched

curl/libcurl version

7.77.0

operating system

NONSTOP_KERNEL myhost L20 10 NSX-D NSX NSX-D NonStop Kernel

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

configure seems to be identifying version 3.0, but does not look like it is acting correctly:

configure:24521: checking for OpenSSL >= v3
configure:24543: cc -c -c99 -D_XOPEN_SOURCE_EXTENDED=1 -Wlp64 -WIEEE_float -I/usr/local-ssl3.0/openssl/include -I/usr/local-ssl3.0/include -I/usr/local-ssl3.0/include/openssl conftest.c >&5
   return 0;
   ^
"/home/ituglib/randall/jenkins/.jenkins/workspace/Curl_3.0_Pipeline/conftest.c",
 line 61: warning(203):          statement is unreachable
configure:24543: $? = 0
configure:24545: result: yes

@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

Why do you provide a lot of custom flags to configure? What happens if you just use plain configure as intended?

Also, configure from 7.77.0 will not build correctly with current OpenSSL built from their git due to how they've changed. Fixed in 1e5e93d. I don't know if beta2 has that change or if that was done later.

We build with OpenSSL3 (from their git master) in the CI, it works. As I told on the mailing list, I build frequently and I did it from source just today. On Linux x86-64.

@bagder bagder added the build label Aug 21, 2021
@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

It helps if you explain more about what exactly in configure that fails. Please show a lot more than just the 6 lines above.

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

Configure, as intended, does not work at all on NonStop. If it did, I promise that I would use it. curl, on the platform, requires FLOSS, which is a platform compatibility library and that has a bunch of flags required.

At this point, we have to build OpenSSL from git, also no choice. I am not able to build from their tarball on this platform.

config.log is huge. What scope can I provide?

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

I'm going to try a 32-bit build of both OpenSSL 3.0.0 (and curl 7.77.0 instead of 64. It is possible that FLOSS is getting in the way of a lot of what configure is trying to do. Will report back when that is installed.

However, 1e5e93d will not fix the issue at all as there is no lib64 (so far anyway) in OpenSSL 3.0 when building in 64-bit on this platform.

@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

checking for OpenSSL headers version... unknown - ( (3<<28) |(0<<20) |(0<<4) |0x0L )

That output is clearly broken with OpenSSL 3 (I'll work on a fix). It's not important to the end result though.

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

checking for OpenSSL headers version... unknown - ( (3<<28) |(0<<20) |(0<<4) |0x0L )

That output is clearly broken with OpenSSL 3 (I'll work on a fix). It's not important to the end result though.

I know. Prior versions used to hard-code the value as a long. I'm 99% sure this value is now derived.

@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

So, apart from configure showing the wrong version there. Is there anything else that fails with v3?

@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

#7608 is a pending fix for this (will amend the commit message)

@bagder bagder linked a pull request that will close this issue Aug 21, 2021
@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

Even with this wrong output by configure, a subsequent build should still show "OpenSSL/3.0.0" in curl -V output.

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

Assuming I could get it built, it should. Still working on that part - it will be at least Wednesday before I have an answer.

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

I did check the OpenSSL 3.0 configuration scripts and cannot find a ref to lib64. This may be set by --libdir or LIBDIR in a custom build. I have asked others at OpenSSL about it and will conform our platform's 50-nonstop.conf to match.

@bagder
Copy link
Member

@bagder bagder commented Aug 21, 2021

$ cd $openssl-source-tree
$ ./config enable-tls1_3 --prefix=/home/daniel/build-openssl
$ make
$ git describe 
openssl-3.0.0-beta2-79-g43044ede54
$ grep ^LIBDIR Makefile
LIBDIR=lib64

@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 21, 2021

$ cd $openssl-source-tree
$ ./config enable-tls1_3 --prefix=/home/daniel/build-openssl
$ make
$ git describe 
openssl-3.0.0-beta2-79-g43044ede54
$ grep ^LIBDIR Makefile
LIBDIR=lib64

Please forgive me for belabouring the point, but Makefile is generated by the OpenSSL 3 Configure perl script, so the lib64 is likely coming from your specific configuration. When I generate the default configurations for nonstop_nsx or Cygwin-X86_64, which are both 64-bit configurations, lib is selected.

@bagder
Copy link
Member

@bagder bagder commented Aug 22, 2021

I think it just shows even better how crazy the decision to use lib64 in some circumstances is. You said you couldn't find it anywhere so I showed you how it could appear in a build.

@bagder bagder closed this in f09030b Aug 22, 2021
@rsbeckerca
Copy link
Author

@rsbeckerca rsbeckerca commented Aug 23, 2021

I understand now. The lib64 comes from multilib => '64' attribute in your configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants