Skip to content

Conversation

@jcgraybill
Copy link
Contributor

@jcgraybill jcgraybill commented Jul 25, 2025

Hi @mistydemeo and @sevan,

I've been looking at which versions of erlang, and packages that use it, run on old Mac OS X versions. The conclusion is that it would be possible to upgrade Tigerbrew's erlang to 23.3.4.20 - which is a patch release from March 2024. (Erlang 23 itself was released in 2020).

Here's a PR for that version. It also removes some build options and config flags that aren't used any longer. This version of erlang must be built with at least gcc-4.4, and tbh I'm not sure I specified that in the right way in this formula.

Offering this version would mean some tradeoffs in support of packages that use erlang. Several can or must be upgraded themselves to newer versions to stay compatible. Some projects that stopped receiving patches a long time ago have no compatible version available, and would need to be deprecated. On the other hand, support increased for things like rabbitmq. It's possible that this would enable adding a Gleam package to Tigerbrew, but I haven't looked into that too deeply.

I'll submit an accompanying draft PR that includes the best updates I've been able to find for everything that uses erlang. If you decide to merge this erlang version upgrade, I'll be happy to submit each of those as individual follow-on PRs.

@sevan
Copy link
Collaborator

sevan commented Jul 28, 2025

Thanks for working on this.
Got curious and tried to build it on a G4 running Tiger with GCC 4.0.1. Worked fine. (what does the output of gcc-4.0 -v say on Tiger for you? mine: gcc version 4.0.1 (Apple Computer, Inc. build 5370))
Tried to switch to use OpenSSL 3.5 but it looks like Erlang's crypto library relies on functionality removed in OpenSSL 3.0 (FIPS_mode()).

crypto.so and otp_test_engine.so in lib/erlang/lib/crypto-4.9.0.4/priv/lib are what link to OpenSSL.

Took 76 minutes on a 1.33Ghz PowerBook G4 with GCC 4.0.1 on Tiger.
20 minutes on a 2Ghz intel mac mini with GCC 4.0.1 on Tiger.

@sevan
Copy link
Collaborator

sevan commented Jul 28, 2025

Ok, I hit the issue on Leopard when attempting to build it with GCC 4.2.

	  -lutil -ldl -lm    -lncurses -L../lib/internal/powerpc-apple-darwin9.8.0  -lz /private/tmp/erlang20250728-281-1qacq5n/otp-OTP-23.3.4.20/erts/emulator/pcre/obj/powerpc-apple-darwin9.8.0/opt/libepcre.a  -lethread -lerts_internal_r -lpthread    -framework Carbon -framework Cocoa
ld: in obj/powerpc-apple-darwin9.8.0/opt/smp/erl_process.o, malformed .o file, symbol _erts_system_monitor_long_schedule with address 0x26110 is not with section 5 (__DATA,ERTS_LOW_WRITE) address range of 0x260E0 to 0x260F0
collect2: ld returned 1 exit status

hmm, reattempting with ld64 added as build dep.

@jcgraybill
Copy link
Contributor Author

Ok, I hit the issue on Leopard when attempting to build it with GCC 4.2.

	  -lutil -ldl -lm    -lncurses -L../lib/internal/powerpc-apple-darwin9.8.0  -lz /private/tmp/erlang20250728-281-1qacq5n/otp-OTP-23.3.4.20/erts/emulator/pcre/obj/powerpc-apple-darwin9.8.0/opt/libepcre.a  -lethread -lerts_internal_r -lpthread    -framework Carbon -framework Cocoa
ld: in obj/powerpc-apple-darwin9.8.0/opt/smp/erl_process.o, malformed .o file, symbol _erts_system_monitor_long_schedule with address 0x26110 is not with section 5 (__DATA,ERTS_LOW_WRITE) address range of 0x260E0 to 0x260F0
collect2: ld returned 1 exit status

hmm, reattempting with ld64 added as build dep.

Interesting - when I was building this a few weeks ago, what I ran into was that Leopard Intel and Snow Leopard Intel needed GCC 4.4, but that other versions could actually build with the OS-default GCC or GCC 4.4. My notes on that are here jcgraybill#1 (comment). Let me try doing a cleaner run of builds on that now, to see if that still holds.

I also tried openssl3 builds: that was compatible with Erlang/OTP version 24 and above, but those builds broke due to other issues. Erlang/OTP 23 does come with this configuration option:

  --disable-fips          disable OpenSSL FIPS mode support (default)

But since it's off by default, it looks like it still depends on FIPS symbols even if support is disabled?

@jcgraybill
Copy link
Contributor Author

jcgraybill commented Jul 29, 2025

Indeed, as you reported, erlang fails to build on Leopard PowerPC with the default gcc. Here are build outputs from brew install erlang commands just now - no gcc version specified - on various OS versions & architectures:

@sevan
Copy link
Collaborator

sevan commented Jul 30, 2025

I also tried openssl3 builds: that was compatible with Erlang/OTP version 24 and above, but those builds broke due to other issues. Erlang/OTP 23 does come with this configuration option:

  --disable-fips          disable OpenSSL FIPS mode support (default)

But since it's off by default, it looks like it still depends on FIPS symbols even if support is disabled?

Yes, I get the impression the function was used for detecting if FIPS was available.

@sevan
Copy link
Collaborator

sevan commented Jul 30, 2025

* ⛔️ Tiger Intel: https://gist.github.com/jcgraybill/82cbd24d91e2352b3cd3fbe2af0ac452

Looks like you built with GCC 4.2 via apple-gcc42. Either unlink or uninstall apple-gcc42 or pass --cc=gcc-4.0 to brew install

* ⛔️ Leopard PowerPC (G4): https://gist.github.com/jcgraybill/2153cd6fcea66b1a2c6c922a70d984fc

Yep, though I shared the error when it comes to linking, it warns when building erl_process.o as seen in your gist.

gcc-4.2  -Werror=undef -Werror=implicit -Werror=return-type  -std=gnu99 -fno-common -g  -O3 -fomit-frame-pointer -I/private/tmp/erlang20250729-175-igs5ak/otp-OTP-23.3.4.20/erts/powerpc-apple-darwin9.8.0    -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS   -Ipowerpc-apple-darwin9.8.0/opt/smp -Ibeam -Isys/unix -Isys/common -Ipowerpc-apple-darwin9.8.0 -Ipcre -Ihipe -I../include -I../include/powerpc-apple-darwin9.8.0 -I../include/internal -I../include/internal/powerpc-apple-darwin9.8.0 -c beam/erl_process.c -o obj/powerpc-apple-darwin9.8.0/opt/smp/erl_process.o
{standard input}:45421:section type does not match previous section type
{standard input}:45429:section type does not match previous section type
{standard input}:45453:section type does not match previous section type
{standard input}:45455:section type does not match previous section type
{standard input}:45457:section type does not match previous section type
{standard input}:45459:section type does not match previous section type
{standard input}:45461:section type does not match previous section type
{standard input}:45463:section type does not match previous section type
{standard input}:45465:section type does not match previous section type
{standard input}:45467:section type does not match previous section type
{standard input}:45471:section type does not match previous section type
{standard input}:45473:section type does not match previous section type
{standard input}:45475:section type does not match previous section type
{standard input}:45477:section type does not match previous section type
{standard input}:17886:section difference relocatable subtraction expression, "_erts_no_total_schedulers" minus "L00000000110$pb" using a symbol at the end of section will not produce an assembly time constant
{standard input}:17886:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = _erts_no_total_schedulers - L00000000110$pb
{standard input}:17879:section difference relocatable subtraction expression, "_erts_no_total_schedulers" minus "L00000000110$pb" using a symbol at the end of section will not produce an assembly time constant
{standard input}:17879:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = _erts_no_total_schedulers - L00000000110$pb

@sevan
Copy link
Collaborator

sevan commented Jul 30, 2025

I was able to bodge past the issue on 10.5 by initialising a bunch of variables and GCC 4.2 was happy to compile erts/emulator/beam/erl_process.c and link beam without issue.
However as it was a bodge, the generated beam.smp is actually useless since it bus error'd at the next stage when trying to build HiPE.
The variables are marked with the ERTS_WRITE_UNLIKELY macro which on OS X adds attributes.
When the linker is complaining about __DATA,ERTS_LOW_WRITE it's those attributes (see erts/emulator/beam/sys.h.

Looks like there's a different issue on 10.6 with the same file (erl_process.c)?

@jcgraybill
Copy link
Contributor Author

I was able to bodge past the issue on 10.5 by initialising a bunch of variables and GCC 4.2 was happy to compile erts/emulator/beam/erl_process.c and link beam without issue. However as it was a bodge, the generated beam.smp is actually useless since it bus error'd at the next stage when trying to build HiPE. The variables are marked with the ERTS_WRITE_UNLIKELY macro which on OS X adds attributes. When the linker is complaining about __DATA,ERTS_LOW_WRITE it's those attributes (see erts/emulator/beam/sys.h.

Nice! I don't know whether the HiPE issue is HiPE-specific, or is symptomatic of a broader incompatiblity in erl_process.c. If it's the former, one possibility is to build Tigerbrew erlang with HiPE disabled altogether. From this discussion it looks like by Erlang 23 the maintainers had all but turned away from it, and were discussing removing it from Erlang 24.

@jcgraybill
Copy link
Contributor Author

* ⛔️ Tiger Intel: https://gist.github.com/jcgraybill/82cbd24d91e2352b3cd3fbe2af0ac452

Looks like you built with GCC 4.2 via apple-gcc42. Either unlink or uninstall apple-gcc42 or pass --cc=gcc-4.0 to brew install

🤦🏻‍♂️ Looks like I was moving too fast there. Indeed, without apple-gcc42, erlang builds successfully on Tiger Intel. https://gist.github.com/jcgraybill/e7c830e2a578d3daa6c699b46a56daf2

@sevan
Copy link
Collaborator

sevan commented Jul 31, 2025

Nice! I don't know whether the HiPE issue is HiPE-specific, or is symptomatic of a broader incompatiblity in erl_process.c. If it's the former, one possibility is to build Tigerbrew erlang with HiPE disabled altogether. From this discussion it looks like by Erlang 23 the maintainers had all but turned away from it, and were discussing removing it from Erlang 24.

I think my change was the culprit since invoking beam.smp by itself would generate the same error. Need to speed some more time and do things correctly instead.

@jcgraybill
Copy link
Contributor Author

Oh, and I had meant to answer this:

(what does the output of gcc-4.0 -v say on Tiger for you?

Tiger PowerPC: gcc version 4.0.1 (Apple Computer, Inc. build 5370)
Tiger Intel: gcc version 4.0.1 (Apple Computer, Inc. build 5370)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants