Skip to content

Configure fails to identify OpenSSL 3.0.0 headers #7606

Closed
Closed
Configure fails to identify OpenSSL 3.0.0 headers#7606
Labels
build

Description

@rsbeckerca
rsbeckerca
opened on 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

Activity

  1. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

    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

  2. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

    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.

  3. bagder
    added
    build
    on Aug 21, 2021

  4. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

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

  5. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

    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?

  6. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

    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.

  7. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

    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.

  8. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

    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.

  9. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

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

  10. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

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

  11. bagder
    linked a pull request that will close this issuecurl-openssl.m4: show correct output for OpenSSL v3 #7608on Aug 21, 2021

  12. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member

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

  13. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

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

  14. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor

    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.

  15. bagder commented on Aug 21, 2021

    @bagder
    bagder
    on Aug 21, 2021
    Member
    $ 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

  16. rsbeckerca commented on Aug 21, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 21, 2021
    ContributorAuthor
    $ 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.

  17. bagder commented on Aug 22, 2021

    @bagder
    bagder
    on Aug 22, 2021
    Member

    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.

  18. bagder
    closed this as completedin f09030bon Aug 22, 2021

  19. rsbeckerca commented on Aug 23, 2021

    @rsbeckerca
    rsbeckerca
    on Aug 23, 2021
    ContributorAuthor

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

  20. jay
    added a commit that references this issue on Mar 4, 2022

    curl-openssl.m4: prefer lib64 over lib

    1beaf84
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    build

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions