INC and LIBS are hardcoded

[ikedas]

Description

I tried to automate testing of Sympa with GitHub Actions workflow, then have a problem with macOS environment: It has both openssl@3 and openssl@1.1 installed, hardcoded inc and libs in Makefile.PL point the former and therefore building module fails.

Specifying INC=... and LIBS=... as command line arguments for MakeMaker is discouraged. Because it can break build of the other modules, as we use the package manager cpanm.

Expected behaviour

It would be nice to be able to specify INC and LIBS of C::O::X509's own. Or, some more precise way to specify them, like PKG_CONFIG_PATH environment variable, is desirable.

Actual behaviour

On Unixen systems INC and LIBS are hardcoded as /usr/local/opt/openssl/* and so on.

Special suffixes like /usr/local/opt/openssl@1.1 (on GH's virtual env.), /opt/homebrew/opt/openssl@1.1 (default location of recent homebrew) and so on cannot be specified.

Operating system and version

macOS 10.15 (and maybe later) with homebrew, provided by GitHub Actions virtual environment.

Crypt::OpenSSL::X509 version

1.910.

Perl version

5.16 to 5.34, provided by shogo82148/actions-setup-perl.

OpenSSL version

We want to use openssl@1.1 (1.1.1i), but openssl@3 (3.0.0) is used.

Output, if available

  /Users/runner/hostedtoolcache/perl/5.32.1/x64/bin/perl /Users/runner/work/_actions/shogo82148/actions-setup-perl/v1/bin/cpanm --local-lib-contained local --notest --verbose --no-interactive --with-develop --with-feature=Data::Password --with-feature=ldap --with-feature=safe-unicode --with-feature=smime --with-feature=soap --with-feature=sqlite --installdeps .
  cpanm (App::cpanminus) 1.9019 on perl 5.032001 built for darwin-2level
(...)
  --> Working on Crypt::OpenSSL::X509
  Fetching http://www.cpan.org/authors/id/J/JO/JONASBN/Crypt-OpenSSL-X509-1.910.tar.gz ... Searching Crypt::OpenSSL::X509 (1.909) on cpanmetadb ...
  OK
  Unpacking Crypt-OpenSSL-X509-1.910.tar.gz
(...)
  cc -c  -I/usr/local/opt/openssl@3/include -fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV -O2 -g -Wall -Werror   -DVERSION=\"1.910\" -DXS_VERSION=\"1.910\"  "-I/Users/runner/hostedtoolcache/perl/5.32.1/x64/lib/5.32.1/darwin-2level/CORE"   X509.c
  X509.xs:157:3: error: 'BIO_set_callback' is deprecated [-Werror,-Wdeprecated-declarations]
    BIO_set_callback(bio, bio_write_cb);
    ^
  /usr/local/opt/openssl@3/include/openssl/bio.h:277:1: note: 'BIO_set_callback' has been explicitly marked deprecated here
  OSSL_DEPRECATEDIN_3_0 void BIO_set_callback(BIO *b, BIO_callback_fn callback);
  ^
  /usr/local/opt/openssl@3/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
  #   define OSSL_DEPRECATEDIN_3_0                OSSL_DEPRECATED(3.0)
                                                  ^
  /usr/local/opt/openssl@3/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
  #     define OSSL_DEPRECATED(since) __attribute__((deprecated))
                                                     ^
(...)
  fatal error: too many errors emitted, stopping now [-ferror-limit=]
  20 errors generated.
  make: *** [X509.o] Error 1
  FAIL
(...)

Step by step guide to reproducing the issue

• Workflow definition
• cpanfile

[jonasbn]

Hi @ikedas

From the output you have included, it seems as if you are using OpenSSL 3, this is currently not supported, please see issue #91.

The Makefile.PL uses the path from brew dynamically, is it different for this particular environment? This repositorys own actions report no issues with the implemented approach.

[jonasbn]

Successful builds using own actions can be located here

[ikedas]

Only some of builds are unsuccsessful (build logs are here). Because, some virtual environments for macOS have both openssl 3 & 1.1 and /usr/local/opt/openssl links to openssl@3, while some others have only 1.1 and openssl@1.1 is used. The former ones fail to build, and the latter ones success.

[michal-josef-spacek]

@ikedas I believe that #104 will help to move to resolving bugs with OpenSSL 3.

[ikedas]

@ikedas I believe that #104 will help to move to resolving bugs with OpenSSL 3.

It looks promising for me. I'll try it if it will be included in the next release. Thanks!

[jonasbn]

This is believed to be addressed via #104, we will reopen or create new issue if the challenges persist

[jonasbn]

Hi @ikedas and @michal-josef-spacek

This has been included in the release 1.9.14-TRIAL, just uploaded to PAUSE/CPAN.

Please let me know if you experience any issues or have any feedback. The 1.9.14 release will be made in due time depending on the outcome/feedback of the trial release.

Thanks for your contributions.