Build fixes for ARM - Githubissues

Homebrew / homebrew-portable-ruby

🚗 Versions of Ruby that can be installed and run from anywhere on the filesystem.

BSD 2-Clause "Simplified" License

128 stars 43 forks source link

Build fixes for ARM #212

Closed Bo98 closed 2 months ago

Bo98 commented 2 months ago

Thanks to Apple Silicon, testing whether a Portable Ruby builds in a Linux ARM container takes just a few minutes.

Scope glibc@2.13 reqiurement to Linux only
- This effectively means that ARM support will require glibc 2.35 as a minimum, which seems reasonable to start clean for a new architecture and worry about our glibc formulae later down the line.
portable-openssl: disable afalgeng
- The test for it seems to fail in aarch64 containers. It might not necessarily will have in a theoretical future CI but it's not a feature we ever use so I opted to disable the feature entirely (Ruby's openssl gem does not allow engines to be enabled when using OpenSSL >=3.0).
- All engines in general are deprecated in OpenSSL itself anyway afaik. Given the Ruby gem dropped support already, maybe we can slim the build further and just do no-engine?

Bo98 commented 2 months ago

All engines in general are deprecated in OpenSSL itself anyway afaik. Given the Ruby gem dropped support already, maybe we can slim the build further and just do no-engine?

Ended up just doing this. OpenSSL test suite is fairly large so shaving off things like this can save some build time there.

MikeMcQuaid commented 2 months ago

If we want to have broader coverage, we may want to introduce glibc@2.17, the first Glibc with aarch64 support. Tested to work.

@ZhongRuoyu This makes sense, can you submit a PR!

Currently bottling things on aarch64 Linux can be painfully slow because brewed gnu-tar is required but not bottled, and has a huge build dependency tree due to this dependency chain: gnu-tar -> acl -> attr -> gettext -> libxml2 -> python@3.11, python@3.12, ...

We should just use the system gnu-tar on ARM instead. Similarly, a Homebrew/brew PR would be appropriate I think.

MikeMcQuaid commented 2 months ago

Thanks @Bo98!

Bo98 commented 2 months ago

If we want to have broader coverage, we may want to introduce glibc@2.17, the first Glibc with aarch64 support. Tested to work.

You would not only need to add a glibc@2.17 but also update regular glibc to support being bootstrapped on aarch64 since that will be auto installed for 2.17-2.34.

It's something we would need to do eventually in any case if we ever moved from 2.35 in the future so if someone is able to do that prior to us adding support for aarch64 here then 2.17 minimum should be fine.

Bo98 commented 2 months ago

Currently bottling things on aarch64 Linux can be painfully slow because brewed gnu-tar is required but not bottled, and has a huge build dependency tree due to this dependency chain: gnu-tar -> acl -> attr -> gettext -> libxml2 -> python@3.11, python@3.12, ...

That sounds like a ridiculous dependency tree. I might have to take a look at that...

Bo98 commented 2 months ago

Opened some Homebrew/core PRs to fix that dependency tree.

Although I've fixed the gnu-tar case, we still really should split the Python bindings from libxml2 as libxml2 with that large dependency tree is used in a lot of formulae and is a pain point that has very commonly come up at this point.