ruby26 @2.6.8_2 and ruby30 @3.0.2_1 build fails against openssl v3.0.0

[kencu (Ken)]

using openssl 3.0.0 from here

​https://github.com/macports/macports-ports/pull/12410

the rebuild of ruby26 fails:

:info:build ossl_pkey_rsa.c:942:5: error: use of undeclared identifier 'RSA_SSLV23_PADDING'
:info:build     DefRSAConst(SSLV23_PADDING);
:info:build     ^
:info:build ossl_pkey_rsa.c:877:58: note: expanded from macro 'DefRSAConst'
:info:build #define DefRSAConst(x) rb_define_const(cRSA, #x, INT2NUM(RSA_##x))
:info:build                                                          ^
:info:build <scratch space>:193:1: note: expanded from here
:info:build RSA_SSLV23_PADDING
:info:build ^
:info:build 115 warnings and 1 error generated.
:info:build make[2]: *** [ossl_pkey_rsa.o] Error 1

[kencu (Ken)]

hmm. Neither method of forcing openssl11 worked with ruby26. It still finds the installed openssl 3.0.0 and errors in various ways.

[kencu (Ken)]

this project pinned openssl 1.1 for a version of ruby

​https://github.com/postmodern/ruby-install/issues/409

[kencu (Ken)]

our method of providing both openssl10 and openssl11 might have to be altered to also include a simple --with-openssl= layout, something like this:

/path/to/openssl-1.1/include/*
/path/to/openssl-1.1/lib/*

ruby 2.6 has a --with-openssl= option, but I can't find something where the headers and libs can be separately specified it seems, at least without hacking into the ruby build scripts...

If you first deactivate openssl, then ruby26 will build against openssl11 using the build_flags method:

% port -v installed ruby26
The following ports are currently installed:
  ruby26 @2.6.8_2 (active) requested_variants='' platform='darwin 20' archs='x86_64' date='2021-09-29T16:12:01-0700'

% port contents ruby26 | grep openssl.bundle
  /opt/local/lib/ruby2.6/2.6.0/x86_64-darwin20/openssl.bundle

% otool -L  /opt/local/lib/ruby2.6/2.6.0/x86_64-darwin20/openssl.bundle
/opt/local/lib/ruby2.6/2.6.0/x86_64-darwin20/openssl.bundle:
	/opt/local/lib/libruby.2.6.dylib (compatibility version 2.6.0, current version 2.6.8)
	/opt/local/lib/openssl-1.1/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/opt/local/lib/openssl-1.1/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

[kencu (Ken)]

Making a typical directory structure as above:

/path/to/openssl-1.1/include/*
/path/to/openssl-1.1/lib/*

like this, for example:

sudo mkdir /opt/local/libexec/openssl11
sudo mkdir /opt/local/libexec/openssl11/include
sudo ln -s /opt/local/include/openssl-1.1/openssl /opt/local/libexec/openssl11/include/
sudo ln -s /opt/local/lib/openssl-1.1 /opt/local/libexec/openssl11/lib

so that we have this typical structure in the end:

% ls -la /opt/local/libexec/openssl11
total 0
drwxr-xr-x  4 root  wheel  128 29 Sep 16:45 .
drwxr-xr-x  9 root  wheel  288 29 Sep 17:01 ..
drwxr-xr-x  3 root  wheel   96 29 Sep 16:44 include
lrwxr-xr-x  1 root  wheel   26 29 Sep 16:45 lib -> /opt/local/lib/openssl-1.1

% ls -la /opt/local/libexec/openssl11/include
total 0
drwxr-xr-x  3 root  wheel   96 29 Sep 16:44 .
drwxr-xr-x  4 root  wheel  128 29 Sep 16:45 ..
lrwxr-xr-x  1 root  wheel   38 29 Sep 16:44 openssl -> /opt/local/include/openssl-1.1/openssl

we can then add the usual argument to ruby

--with-openssl-dir="${prefix}/libexec/openssl11"

and all is well, ruby30 (at least 30) builds against openssl-1.1 even if openssl-3.0 is installed:

% port -v installed ruby30 openssl openssl11
The following ports are currently installed:
  openssl @3.0.0_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-09-29T15:06:28-0700'
  openssl11 @1.1.1l_0 (active) requested_variants='' platform='darwin 20' archs='x86_64' date='2021-09-29T09:18:06-0700'
  ruby30 @3.0.2_1 (active) requested_variants='' platform='darwin 20' archs='x86_64' date='2021-09-29T17:01:06-0700'

and it is linked properly:

% otool -L /opt/local/lib/ruby3.0/3.0.0/x86_64-darwin20/openssl.bundle
/opt/local/lib/ruby3.0/3.0.0/x86_64-darwin20/openssl.bundle:
	/opt/local/lib/libruby.3.0.dylib (compatibility version 3.0.0, current version 3.0.2)
	/opt/local/lib/openssl-1.1/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/opt/local/lib/openssl-1.1/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

so it would appear that the openssl10 and openssl11 ports could be modified to add those directory structures.

[kencu (Ken)]

I am still not sure what we do about libressl though, for these ports that need to fallback to openssl11...

[kencu (Ken)]

and ruby26 likes that fix too.

[kencu (Ken)]

there is work going on here ​https://github.com/ruby/openssl/issues/369 and in a related PR to make ruby work with openssl 3.0 directly, so using the 1.1 fallback won't always be needed, at least for newer rubies that get updated...

[ken-cunningham-webuse]

In 432c9bfc93e3ff01e900ed1d1e18e82a9e851e89/macports-ports (master):

openssl11: add a compatability dir

some software, like ruby, expects openssl to
be installed all in one directory

our existing openssl10 and the new openssl11 that
followed openssl10 do things slightly differently

add a compatability directory in ${prefix}/libexec that
makes a typicsl openssl install directory to support
software that wants that

see: #63550

[ken-cunningham-webuse]

In 8e2f54847de6bef47b90b91ea862b4ba6e0719d6/macports-ports (master):

openssl10: add a compatability dir

some software expects openssl to
be installed all in one directory

our existing openssl10 and the new openssl11 that
followed openssl10 do things slightly differently

add a compatability directory in ${prefix}/libexec that
makes a typicsl openssl install directory to support
software that wants that

see: #63550

[fhgwright (Fred Wright)]

When I was working on ruby?? last year, I ran into a build problem with ruby22 on 10.15 related to its use of openssl10. I partially investigated, and found that the problem was that, even though the path to openssl10 was being supplied explicitly in the configure args, there was still something in the build procedure that was using pkg-config to locate openssl, and finding the standard one instead of the alternate. With the openssl port active, this resulted in its trying to build with a mixture of openssl versions, and failing due to incompatibilities. With the openssl port inactive, the build would succeed, but examination of config.log showed that it had internally disabled openssl support. This is a silent failure that would go unnoticed until someone actually tried to use some ruby feature dependent on openssl. The build failure would never show up in a CI test, since the CI setup doesn't activate non-dependencies.

I have no idea why it only showed up under 10.15, or why it didn't affect ruby23 (which also uses openssl10), but that's what I saw. I was able to fix it by defining PKG_CONFIG_PATH to point to the openssl10 location, but there was some other unresolved issue that kept me from pushing the fix.

Around that time, I decided to punt on further ruby?? work, but it's something that needs further investigation, especially if usage of alternate openssl versions becomes more common.

[kencu (Ken)]

there is no plan to try to make ruby work against openssl 3, so this ticket is kinda useless. It was only ever to document the fact that ruby would not build against openssl 3 and why a workaround was needed, but a workaround is no longer needed anyway.