gh-143120: pixi builds for free-threading and TSAN

[crusaderky]

Follow-up to #142469

• Add pixi infrastructure for
  • freethreading: compiles with --disable-gil
  • tsan-freethreading: compiles with --disable-gil --with-thread-sanitizer
• Refactor recipes:
  • Make recipe.yaml and pixi.toml all identical symlinks
  • Remove clang-19 since we are not building the experimental jit
  • Remove ld_impl because we are not hacking the makefiles
  • Add site_packages_path
• Add support for MacOS Intel (specifically macos-15-intel github runners)
• Signal support for Linux ARM (it already worked but was insofar untested)
• Remove ASAN/TSAN DLLs hack on MacOS

Tested in CI on https://github.com/crusaderky/hdf5-pixi

• Issue: Add pixi builds for TSan + free-threading to aid downstream development. #143120

[crusaderky]

copy-paste of asan/recipe.yaml, except this one line

[crusaderky]

copy-paste of asan/pixi.toml

[crusaderky]

copy-paste of asan/recipe.yaml, except this one line

[lucascolley]

@kumaraditya303 @lucascolley any idea what's wrong here?

no clue sorry I haven't seen this before

[crusaderky]

The tsan crash is due to the default mmap_rnd_bits on Ubuntu 24.04; it goes away after lowering it:

$ sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 32  # too high
$ sudo sysctl vm.mmap_rnd_bits=28  # reduce it
vm.mmap_rnd_bits = 28

ubuntu-latest github actions workers seems to be unaffected.

[hugovk]

There's a lot of copy/paste here, which can make maintenance harder. Does pixi have some concept of code reuse or parametrisation? Maybe not the best example, but something like GitHub Actions' reusable workflows?

[ngoldbaum]

@lucascolley is there anything we can do right now to reduce the duplication here? Or does that require fixes in pixi?

[lucascolley]

As mentioned in the README already, this is blocked on prefix-dev/pixi#4599.

[ngoldbaum]

I opened an issue which is needed to make this mergeable. I'm also playing with a NumPy recipe based on this.

[crusaderky]

Ready for final review

[crusaderky]

The issue was that c_compiler is not a defined variable, and comparisons to undefined variables always return false.
So these two would always evaluate to false:

      - if: c_compiler == "gcc" and "san" in variant
        then:
          - libsanitizer
      - if: c_compiler == "clang" and "san" in variant
        then:
          - libcompiler-rt

Linux happened to work because, at least on ubuntu-latest and on my desktop, libasan.so and libtsan.so are installed by default system-wide.

I've opened an improvement ticket upstream: prefix-dev/pixi#5393

[crusaderky]

I've removed the symlinks and replaced them with physical copies + a sync script.
This PR has no known outstanding issues and should be ready for final review and merge.

[crusaderky]

Gentle ping.
This PR has no known outstanding issues and should be ready for final review and merge.

[lucascolley]

trying this out downstream — I get a solve failure for an env that includes the ASAN Python on this branch, ASAN NumPy on main, compilers, and pythran: https://gist.github.com/lucascolley/2d4335f7f80b770a9aec702e7a8f75f8

removing the pythran dependency results in a successful solve. Any ideas @crusaderky @isuruf ?

[crusaderky]

trying this out downstream — I get a solve failure for an env that includes the ASAN Python on this branch, ASAN NumPy on main, compilers, and pythran: https://gist.github.com/lucascolley/2d4335f7f80b770a9aec702e7a8f75f8

removing the pythran dependency results in a successful solve. Any ideas @crusaderky @isuruf ?

ASAN NumPy on main points to a specific commit of CPython main. Could you try repointing numpy to numpy/numpy#30510 ?

[dependencies]
python.git = "https://github.com/crusaderky/cpython"
python.rev = "tsan"
python.subdirectory = "Tools/pixi-packages/asan"
numpy.git = "https://github.com/ngoldbaum/numpy"
numpy.rev = "tsan-ft-pixi"
numpy.subdirectory = "pixi-packages/asan"

[crusaderky]

Anyway your problem is that you have an upper pin for python in pythran:

  │  ├─ pythran 0.16.1 | 0.17.0 would require
  │  │  └─ python >=3.13.0rc1,<3.14.0a0, which cannot be installed because there are no viable options:

but this recipe builds Python 3.15.
You can backport the whole directory to your fork of the 3.13 branch to work around it (and then fork numpy as well and repoint your fork of numpy to your fork of cpython 3.13).

Alternatively you can fork pythran and just remove the pin and hope it was just out of an abundance of caution.

[lucascolley]

Anyway your problem is that you have an upper pin for python in pythran

ah thanks, makes sense. Using pythran from git source may get around the issue in the short-term

[kumaraditya303]

I tested the tsan+freethreading pixi config with the following and it worked:

[workspace]
channels = ["conda-forge"]
name = "cpython-pixi-test"
platforms = ["linux-64"]
preview = ["pixi-build"]

[dependencies]
python = { git = "https://github.com/crusaderky/cpython", rev = "tsan", subdirectory = "Tools/pixi-packages/tsan-freethreading" }

I'll merge this by tomorrow if there are no objections.

[hugovk]

No need to update the README.md right now, but noting this repo has been archived and the new PR is at prefix-dev/pixi#5364.

[hugovk]

Tip for next time: bash for when there's only commands, and console for when there's commands with output. Compare:

$ sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 32  # too high for TSan
$ sudo sysctl vm.mmap_rnd_bits=28  # reduce it
vm.mmap_rnd_bits = 28

$ sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 32  # too high for TSan
$ sudo sysctl vm.mmap_rnd_bits=28  # reduce it
vm.mmap_rnd_bits = 28