openssl @1.1.1l: build failure On Mac OS X 10.4.11: rand.h now uses Availability.h instead of AvailabilityMacros.h

[alex-free (Alex Free)]

Tiger uses /usr/include/AvailabilityMacros.h. On all newer Mac OS X versions, this header is named /usr/include/Availability.h. I have confirmed that by using an ugly hack of symlinking /usr/include/AvailabilityMacros.h to /usr/include/Availability.h that this builds. Will be learning more about MacPorts to submit a patch if someone else doesn't beat me to it soon.

DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/idea/i_cbc.o crypto/idea/i_cbc.c
/opt/local/bin/gcc-apple-4.2  -I. -Iinclude -fPIC -arch i386 -pipe -Os -arch i386 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/local/etc/openssl\"" -DENGINESDIR="\"/opt/local/lib/engines-1.1\"" -D_REENTRANT -DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/idea/i_cfb64.o crypto/idea/i_cfb64.c
/opt/local/bin/gcc-apple-4.2  -I. -Iinclude -fPIC -arch i386 -pipe -Os -arch i386 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/local/etc/openssl\"" -DENGINESDIR="\"/opt/local/lib/engines-1.1\"" -D_REENTRANT -DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/idea/i_ecb.o crypto/idea/i_ecb.c
/opt/local/bin/gcc-apple-4.2  -I. -Iinclude -fPIC -arch i386 -pipe -Os -arch i386 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/local/etc/openssl\"" -DENGINESDIR="\"/opt/local/lib/engines-1.1\"" -D_REENTRANT -DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/idea/i_ofb64.o crypto/idea/i_ofb64.c
/opt/local/bin/gcc-apple-4.2  -I. -Iinclude -fPIC -arch i386 -pipe -Os -arch i386 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/local/etc/openssl\"" -DENGINESDIR="\"/opt/local/lib/engines-1.1\"" -D_REENTRANT -DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/idea/i_skey.o crypto/idea/i_skey.c
/opt/local/bin/gcc-apple-4.2  -I. -Iinclude -fPIC -arch i386 -pipe -Os -arch i386 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/local/etc/openssl\"" -DENGINESDIR="\"/opt/local/lib/engines-1.1\"" -D_REENTRANT -DZLIB -DNDEBUG -I/opt/local/include  -c -o crypto/init.o crypto/init.c
In file included from crypto/init.c:13:
include/crypto/rand.h:24:28: error: Availability.h: No such file or directory
make[1]: *** [crypto/init.o] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_openssl/openssl/work/openssl-1.1.1l'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_openssl/openssl/work/openssl-1.1.1l'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_openssl/openssl/work/openssl-1.1.1l" && /usr/bin/make -j1 -w all 
Exit code: 2
Error: Failed to build openssl: command execution failed
DEBUG: Error code: CHILDSTATUS 21861 2
DEBUG: Backtrace: command execution failed
    while executing
"system {*}$notty {*}$callback {*}$nice $fullcmdstring"
    invoked from within
"command_exec -callback portprogress::target_progress_callback build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_openssl/openssl/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port cmake failed
user

[evanmiller (Evan Miller)]

I'm sure others will chime in but I dealt with a similar issue recently and found a couple of common tactics:

• Use reinplace "s|Availability.h|AvailabilityMacros.h|" on Tiger
• Use the legacysupport PortGroup which as of very recently includes Availability.h. You'll probably want a couple of lines like

PortGroup legacysupport 1.1

# Availability.h
legacysupport.newest_darwin_requires_legacy 8

[kencu (Ken)]

either of those looks good. anyone care to try one and perhaps run the test suite on Tiger?

[kencu (Ken)]

oh -- the reinplace might not work properly I think, because the patch Chris pushed uses the __MACOSX* version of the macros, and those might not be properly defined in AvailabilityMacros.h. Have to double check that fact to be certain.

[evanmiller (Evan Miller)]

Build succeeds on Tiger with the legacysupport solution above.

[kencu (Ken)]

Next thing to ponder is whether we will ever be in a situation where we need openssl to build legacysupport, which would generate a circular dep. Both are fairly core ports...

I don't think so. I have tried very hard to make sure that legacysupport remained as clean and unencumbered as possible.

We'll just have to make sure going forward that it never needs openssl to build.

Or -- a bit of adjustment with the patch, and it would be Tiger-friendly. I think legacysupport is easier, and we'll keep the patch adjustment in our pocket, as it will never be upstreamed I think. I just don't see them moving things around for Tiger at this point in the game, and openssl 3.0 is just about to come out -- it's either RC2 or RC3 now -- they have enough on their plates.

[alex-free (Alex Free)]

Kencu, I think the OpenSSL people may be more understanding then you think. I have been building the latest OpenSSL versions (including some 3.0 alphas) since February of 2020 as part of my PPCMC 7 application which targets Mac OS X 10.3.9+. As of OpenSSL 1.1.1k, this built as is without any modification besides some configure flags using Xcode 2.5 and no macports packages whatsoever (just a newer manually compiled Perl, which was compiled with Xcode 2.5 as well). I think a pull request to upstream may work, I may do so myself to see what the reaction is.

[kencu (Ken)]

Gut Luk :)

[kencu (Ken)]

when I looked at the upstream patch, I knew it was broken for Tiger (see orig ticket). I also knew legacysupport would fix it, when it was pushed here.

I was thinking about fixing the patch for Tiger... but ... life is too short for me to bug upstream openssl for that, when legacysupport is a 1 second fix here, and they are busy like hell with big problems getting 3.0 out the door.

However, sometimes upstreams seem to like doing stuff like this for people, even for ancient niche systems like Tiger, so you might get someone's ear. Or tick them off... you hever know. I put my efforts instead into legacysupport, which IMHO is the fair way for us to treat upstream, if we can.

[ryandesign (Ryan Carsten Schmidt)]

Did [8f45b17de2814464ad2ab5c0c436cee2f87f61c8/macports-ports] fix this?

[fhgwright (Fred Wright)]

Replying to ryandesign:

Did [8f45b17de2814464ad2ab5c0c436cee2f87f61c8/macports-ports] fix this?

Yes. My fix eliminates the need for the include altogether.

[evanmiller (Evan Miller)]

openssl3 will need a similar fix after ​https://trac.macports.org/ticket/63847 is addressed.

[evanmiller (Evan Miller)]

In c7fa5d3d922f7ba3760fb307711741a2892e2d30/macports-ports (master):

openssl3: fix build on Tiger

See: #63409

[neverpanic (Clemens Lang)]

I guess this is fixed then now. Please re-open if this still applies.