swift-corefoundation: locally shadowed symbols are incorrectly ignored

[emilazy]

If you create a static library with a symbol that shadows one in CoreFoundation and then link with both -framework CoreFoundation and that library, the macOS system toolchain will use the one from your static library. Linking with our swift-corefoundation, however, will result in incorrect behaviour. Currently, as of a few days ago, it causes a crash at runtime due to a broken rpath hook; a fix for this is being worked on. Before that, however, we get an arguably worse result: the symbol is resolved from swift-corefoundation instead, leading to the potential of silently incorrect behaviour. This is reproducible as far back as I can go (21.05; it seems earlier versions can't build executables on Ventura).

If darwin.apple_sdk.frameworks.CoreFoundation is used to replace swift-corefoundation then we get correct behaviour even with the nixpkgs toolchain, and if swift-corefoundation is passed in to the system toolchain we get incorrect behaviour. Therefore the issue must be either with the swift-corefoundation package itself, or some behaviour in the toolchain or OS that is special-casing the system CoreFoundation but not ours, rather than being a general linking difference between our toolchain and Apple's. (The former is not wholly implausible, given the dyld cache shenanigans recent macOS releases have.)

Note that this probably only applies to x86_64-darwin; on aarch64-darwin we currently use the system CoreFoundation exclusively (although there's a TODO to fix that). It may apply to dynamic libraries as well as static ones, but I didn't test that.

I have pushed a simple test case to https://github.com/emilazy/nixpkgs-corefoundation-linking-issue; it has a flake with packages to demonstrate all these variations in behaviour and a test.bash script which will build and show output for all of them. (Sorry, I didn't feel like handling pinning multiple nixpkgs for the non-flake case, but there's a default.nix you can manually feed things into if you don't want to use flakes.)

I discovered this while trying to fix e2fsprogs on x86_64-darwin; it seems that before the hook issue broke the build entirely it had been mixing the old vendored CoreFoundation version of its UUID library with its more featureful local copy. That doesn't seem to break anything, but it makes me uneasy.

cc @toonn @reckenrode