cpython: disable no-semantic-interposition on darwin

[mweinelt]

Motivation for this change

Not supported on clang, so let's disable it on darwin.

clang-7: error: unknown argument: '-fno-semantic-interposition'

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Relase notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[vcunat]

@ofborg build python3

[vcunat]

stdenv.cc.isClang might be better, though practical difference is negligible, I suppose. On a quick glance, on aarch64-darwin this apparently isn't a problem due to us using a newer clang in there, but there are some other issues anyway, and perhaps it's OK to have it disabled in there even if not necessary.

[mweinelt]

Indeed, that condition is now closer to the root cause for the decision.

[andir]

In any case we should leave a comment why it doesn't work on there.

[mweinelt]

What it says right now is: not on clang.

I left more details on the commit message, isn't that sufficient?

[jonringer]

commit messages aren't as discoverable when looking at the expression.

[mweinelt]

Fair enough.

[vcunat]

OfBorg says that the first python3-minimal step still doesn't build:

clang -L/nix/store/k69r3dlxjcihncggi4yxr2ljcj1cyf1j-zlib-1.2.11/lib -L/nix/store/szg19c03gyy5fjyclhdcwyi6dc9x9gys-bzip2-1.0.6.0.2/lib -L/nix/store/nl6s07d0nlc52as2aq2vzkjk7z9m4d2z-expat-2.4.1/lib -L/nix/store/b1irkxbsflwj44mb3h79ysbfhzp969zs-xz-5.2.5/lib -L/nix/store/i5x98h09cl8ckklf3brylwri6l43czlx-libffi-3.3/lib -L/nix/store/k69r3dlxjcihncggi4yxr2ljcj1cyf1j-zlib-1.2.11/lib -L/nix/store/szg19c03gyy5fjyclhdcwyi6dc9x9gys-bzip2-1.0.6.0.2/lib -L/nix/store/nl6s07d0nlc52as2aq2vzkjk7z9m4d2z-expat-2.4.1/lib -L/nix/store/b1irkxbsflwj44mb3h79ysbfhzp969zs-xz-5.2.5/lib -L/nix/store/i5x98h09cl8ckklf3brylwri6l43czlx-libffi-3.3/lib   -framework CoreFoundation -o python.exe Programs/python.o -L. -lpython3.9 -ldl    -framework CoreFoundation
DYLD_LIBRARY_PATH=/private/tmp/nix-build-python3-minimal-3.9.5.drv-0/Python-3.9.5 ./python.exe -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
        echo "generate-posix-vars failed" ; \
        rm -f ./pybuilddir.txt ; \
        exit 1 ; \
fi
dyld: lazy symbol binding failed: Symbol not found: ___isOSVersionAtLeast
  Referenced from: /private/tmp/nix-build-python3-minimal-3.9.5.drv-0/Python-3.9.5/libpython3.9.dylib
  Expected in: flat namespace
dyld: Symbol not found: ___isOSVersionAtLeast
  Referenced from: /private/tmp/nix-build-python3-minimal-3.9.5.drv-0/Python-3.9.5/libpython3.9.dylib
  Expected in: flat namespace
/nix/store/6jysbyhc43sjvfiyh1bpvi1n3zbz212r-bootstrap-tools/bin/bash: line 5: 10134 Abort trap: 6           DYLD_LIBRARY_PATH=/private/tmp/nix-build-python3-minimal-3.9.5.drv-0/Python-3.9.5 ./python.exe -E -S -m sysconfig --generate-posix-vars
generate-posix-vars failed
make: *** [Makefile:619: pybuilddir.txt] Error 1
builder for '/nix/store/dbv6f2r28griyb7gmy18kmz9kg7lq9mh-python3-minimal-3.9.5.drv' failed with exit code 2

[sternenseemann]

-fno-semantic-interposition is available from clang 10 onwards. We are looking to use clang 11 as the default on all platforms in the near future (#126411), so we'll be able to reenable this on darwin hopefully soon. Ideally we would do a version check on that conditional, so it could work on aarch64-darwin already today.

[mweinelt]

diff --git a/pkgs/development/interpreters/python/cpython/default.nix b/pkgs/development/interpreters/python/cpython/default.nix
index 997cb1c28ff..757aa2925e5 100644
--- a/pkgs/development/interpreters/python/cpython/default.nix
+++ b/pkgs/development/interpreters/python/cpython/default.nix
@@ -40,7 +40,7 @@
 , static ? stdenv.hostPlatform.isStatic
 , enableOptimizations ? false
 # enableNoSemanticInterposition is a subset of the enableOptimizations flag that doesn't harm reproducibility.
-, enableNoSemanticInterposition ? !stdenv.cc.isClang
+, enableNoSemanticInterposition ? (!stdenv.cc.isClang || (stdenv.cc.isClang && lib.versionAtLeast stdenv.cc.version "10"))
 # enableLTO is a subset of the enableOptimizations flag that doesn't harm reproducibility.
 # enabling LTO on 32bit arch causes downstream packages to fail when linking
 , enableLTO ? stdenv.is64bit

Like this?

[sternenseemann]

Yeah, that's what I had in mind.

[mweinelt]

@GrahamcOfBorg build python3

[mweinelt]

@GrahamcOfBorg build python38

[mweinelt]

The breakage also affects python 3.8. It's not LTO, I tried disabling it and it failed the same.

[mweinelt]

Quoting #macos:nixos.org:

@thefloweringash: I had a quick look. it might be a lack of libclang_rt (aka compiler-rt) in the bootstrap tarball

Can someone familiar with the bootstrap tarballs give that a try?

[vcunat]

Or perhaps use some less problematic python version in the bootstrapping phase?

EDIT: I mean, it seems to have worked fine until the last version bump. As a bonus I suspect we wouldn't rebuild all stdenvs every time the default python needs a patch (though a big rebuild is still unavoidable).

[thefloweringash]

Quoting #macos:nixos.org:

@thefloweringash: I had a quick look. it might be a lack of libclang_rt (aka compiler-rt) in the bootstrap tarball

Can someone familiar with the bootstrap tarballs give that a try?

A little bit more context: I think the bootstrap tools job unintentionally dropped libclang_rt / compiler-rt as part of a clang refactor. There was an earlier PR to include compiler-rt in the bootstrap tools (#94426) which has some discussion. This was then subsumed by the changes for Apple Silicon support (#105026).

The current set of bootstrap tools were generated in the period in nixpkgs where compiler-rt was not present. Earlier tools included it, and tools built from master also now include it. To fix the current python issue, it’s probably enough to update the bootstrap tools.

(Though looking again, the current bootstrap build might include a few too many files with libclang*.a files.)

[vcunat]

It will be best if someone with access to a darwin builder could look into this stdenv blocker. (not me, for example) Ideally they'd also have some knowledge about the darwin stdenv bootstrapping.

[vcunat]

BTW, I see that python 3.9.6 is out. Perhaps one of the fixes might be related to the ___isOSVersionAtLeast error.

[mweinelt]

@GrahamcOfBorg build python39.tests

[vcunat]

The following builds were skipped because they don't evaluate on x86_64-darwin: python39.tests

@ofborg build python39

[vcunat]

No, that error looks the same 😞

dyld: lazy symbol binding failed: Symbol not found: ___isOSVersionAtLeast
  Referenced from: /private/tmp/nix-build-python3-minimal-3.9.6.drv-0/Python-3.9.6/libpython3.9.dylib
  Expected in: flat namespace
dyld: Symbol not found: ___isOSVersionAtLeast
  Referenced from: /private/tmp/nix-build-python3-minimal-3.9.6.drv-0/Python-3.9.6/libpython3.9.dylib
  Expected in: flat namespace
/nix/store/6jysbyhc43sjvfiyh1bpvi1n3zbz212r-bootstrap-tools/bin/bash: line 5: 42728 Abort trap: 6           DYLD_LIBRARY_PATH=/private/tmp/nix-build-python3-minimal-3.9.6.drv-0/Python-3.9.6 ./python.exe -E -S -m sysconfig --generate-posix-vars
generate-posix-vars failed
make: *** [Makefile:619: pybuilddir.txt] Error 1
builder for '/nix/store/znpdfwql7wqwbh6qv3rgman9aqkksfid-python3-minimal-3.9.6.drv' failed with exit code 2

[thefloweringash]

I can confirm that updating bootstrap tools is sufficient to build stdenv / hello. I updated to 20acd4c, which corresponds to hydra build 143075093 and should be very similar to bootstrap tools used by aarch64-darwin. Any build prior to 4a26982 (from #121055) should be fine, since we probably don't want to include llvm 11 in this cycle, since that's still in progress in #126411.

[SuperSandro2000]

@GrahamcOfBorg build python37.tests python38.tests python39.tests