Closed Bo98 closed 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.
- 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.
Thanks @Bo98!
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.
- 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...
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.
Thanks to Apple Silicon, testing whether a Portable Ruby builds in a Linux ARM container takes just a few minutes.
no-engine
?