Two CoreFoundations lead to redefinition errors

[tjni]

Describe the bug

It seems that some packages, such as cargo-watch, depend on CoreFoundation. When they are compiled, there are two different CoreFoundations added to the compiler's path (which can be verified by observing NIX_CFLAGS_COMPILE).

One of them was built with stdenv-darwin. The other was built with bootstrap-stage4-stdenv-darwin. In apple-sdk-11.0, CoreFoundation depends on libobjc, for which two different versions being present produce redefinition errors:

/nix/store/ppiqn1bal7bzix25lj5zxzcq50113qk0-libobjc-11.0.0/include/objc/module.modulemap:1:8: error: redefinition of module 'ObjectiveC'
module ObjectiveC [system] [extern_c] {
       ^
/nix/store/wdnnmrk0wvdws80m3ad3byp86zzl11dq-libobjc-11.0.0/include/objc/module.modulemap:1:8: note: previously defined here
module ObjectiveC [system] [extern_c] {

I think the bootstrap-stage4-stdenv-darwin CoreFoundation comes from extraBuildInputs in stdenv-darwin. I'm not sure what to do about it, however.

Steps To Reproduce

Steps to reproduce the behavior:

1. On aarch64-darwin, nix build .#cargo-watch.

Expected behavior

I don't think two versions of CoreFoundation should be added to the compile path.

Notify maintainers

/cc @NixOS/darwin-maintainers

[eqyiel]

A related thread and workaround #160876 (comment)

[tjni]

The ideal state would be for CoreFoundation to appear once when compiling and linking. Today, CoreFoundation appears once from stdenv and again when some derivation depends on linking to the (impure) system CoreFoundation. In addition, dependencies of CoreFoundation (in this case, libobjc on aarch64-darwin) can appear twice for the same reason. It is this repeating of libobjc that surfaces the redefinition errors.

As an intermediate step, I currently envision removing CoreFoundation from stdenv and declaring the dependency explicitly in derivations that need it. The removed CoreFoundation is from a bootstrap stage, while the explicit one won't be, which should solve the redefinition errors because there will only be one libobjc available.

The CoreFoundation in the stdenv is currently pure, so we'd need to introduce a PureCoreFoundation derivation (which exists, currently called CF by convention) for this purpose.

I plan to start experimenting with this.

/cc @LnL7 @thefloweringash @toonn in case they already know this won't work or have other ideas in the meantime

[tjni]

Encountered a problem with this approach. Building the frameworks depends on MacOSX-SDK, which transitively depends on fetching patches using curl, but curl needs CoreFoundation to build.

[toonn]

I wonder if this conditional is trying to fix the same root problem? This is coming from #189977.

[tjni]

Great find. I have hopes that will resolve the errors seen in cargo-watch.

[tjni]

Closing this because #191235 was merged into staging. To me, it's still ugly that two copies of CoreFoundation can exist on the include path, but I don't have a viable alternative and the underlying problem is now resolved.