sage: sage-tests take too long to run (24+ hrs) on aarch64-darwin

[t0yv0]

Nixpkgs version

• Unstable (26.11)

Describe the bug

When building nix build .#sage on an Apple Macbook Air M2, the tests take a prohibitively long time. I have not been able to see them complete in more than 24 hours of 100% CPU use. I believe hydra builds also time out on these tests, presumably using a more powerful CPU version.

I have not dug too much deeper yet but perhaps it could be beneficial to look into it some more; if linux completes the tests on time it's likely something specific to the math libraries on darwin. Even if the root cause cannot be eliminated perhaps doing some darwin-scoped exemptions to some of the most long running tests can get the system back to green on hydra which can be helpful in flagging regressions.

Steps to reproduce

nix build .sage on aarch64-darwin

Expected behaviour

Testing completes in reasonable time-frame (4 hours? 2 hours?).

Screenshots

No response

Relevant log output

Sampled the long-running process, logs here:

https://gist.github.com/t0yv0/5ae1e536b4b145bb0ddafcd381791a7d

Additional context

No response

System metadata

 - system: `"aarch64-darwin"`
 - host os: `Darwin 25.5.0, macOS 26.5.2`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.28.1`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/store/v68j0dy4xi3k9bv9fxn09pc5l03b1jhl-source`

Are you using nix-darwin?

Yes, I am using nix-darwin.

Notify maintainers

@collares appreciate your thoughts on the right course of action here.

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.
• I assert that I have read the automation/AI policy and that this issue report complies with it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[collares]

Can you determine which test(s) take this long? I think it would suffice to run Sage tests with -T 3600 and look at the resulting timeouts; then you could run the corresponding tests with --verbose to figure out which specific line is taking forever. If you want to run them in the Nix sandbox for reproducibility, you can edit the command line at the end of sage-tests.nix to do so.

With this information, we could disable some tests temporarily on aarch64-darwin while we figure out why they're taking so long, as well as search upstream reports to see if this also happens on other distributions.

[t0yv0]

That's helpful, I'll give it a try.

[t0yv0]

I have been investigating it a bit, and seeing some segfaults and incorrect mwrank_get_precision() behavior. Current hypothesis is that disabling threads on ntl dependency leads to incorrect compilation and linking, as ntl compiled with threads is also present as a transient dependency via eclib and a few other libraries. Investigating.

[collares]

This seems plausible, because Sage does not even build on x86_64-linux if I unscope the change that disabled NTL threads. It fails with: ``` [1193/1773] Linking target src/sage/libs/eclib/mwrank.cpython-314-x86_64-linux-gnu.so FAILED: [code=1] src/sage/libs/eclib/mwrank.cpython-314-x86_64-linux-gnu.so g++ -o src/sage/libs/eclib/mwrank.cpython-314-x86_64-linux-gnu.so src/sage/libs/eclib/mwrank.cpython-314-x86_64-linux-gnu.so.p/meson-generated_src_sage_libs_eclib_mwrank.pyx.cpp.o -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group /nix/store/3b6hnqqpp6pi9lqqs60plhmjs3zgcz7j-eclib-20250627/lib/libec.so -lecl /nix/store/y6g9i1jv7j1x20dj16xnqy3cidjq77fk-flint-3.6.0/lib/libflint.so /nix/store/hd4cbx3hbjsmfyvw68y02gp4rcvs150s-gmp-with-cxx-6.3.0/lib/libgmp.so /nix/store/mx560cjkbif8b1r7q4mr7s01jm4zvkcb-mpfr-4.2.2/lib/libmpfr.so -Wl,--end-group /nix/store/b01rwyg0ii5v8r50yrikcs5af64x0v0q-binutils-2.46/bin/ld.bfd: _ZN3NTL2RR4precE: TLS reference in /nix/store/3b6hnqqpp6pi9lqqs60plhmjs3zgcz7j-eclib-20250627/lib/libec.so mismatches non-TLS reference in src/sage/libs/eclib/mwrank.cpython-314-x86_64-linux-gnu.so.p/meson-generated_src_sage_libs_eclib_mwrank.pyx.cpp.o /nix/store/b01rwyg0ii5v8r50yrikcs5af64x0v0q-binutils-2.46/bin/ld.bfd: /nix/store/3b6hnqqpp6pi9lqqs60plhmjs3zgcz7j-eclib-20250627/lib/libec.so: error adding symbols: bad value collect2: error: ld returned 1 exit status ```

[t0yv0]

Some success making sure every dependency has the same ntl build. This fixes the tests: #545925

[collares]

For my own future reference, the previous Darwin problem was the inverse of the x86-64 problem I described above:

[1213/1773] Linking target src/sage/libs/eclib/mwrank.cpython-314-darwin.so
FAILED: [code=1] src/sage/libs/eclib/mwrank.cpython-314-darwin.so 
clang++  -o src/sage/libs/eclib/mwrank.cpython-314-darwin.so src/sage/libs/eclib/mwrank.cpython-314-darwin.so.p/meson-generated_src_sage_libs_eclib_mwrank.pyx.cpp.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,dynamic_lookup -bundle -Wl,-undefined,dynamic_lookup /nix/store/m0rsgyqnk0hsc9bsid7kf7vdqlhpm7j5-eclib-20250627/lib/libec.dylib -lecl /nix/store/qc0hcvwbv9fhnx57pc4ki0z9m376jk1y-flint-3.6.0/lib/libflint.dylib /nix/store/laz33q7r0h804hars6yn8yfcvlmg2a61-gmp-with-cxx-6.3.0/lib/libgmp.dylib /nix/store/zsz53q9v6vwza8sxc699x01brpx1n1g8-mpfr-4.2.2/lib/libmpfr.dylib
ld: illegal thread local variable reference to regular symbol __ZN3NTL2RR4precE for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)