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

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.

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

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?

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.

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.

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.

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

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

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

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

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.

$ 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.

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.

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