cmake: make Enzyme Apple dynamic_lookup opt-in

[sgasho]

Add ENZYME_APPLE_DYNAMIC_LOOKUP CMake option (default OFF).

It turns out that we cannot use std::autodiff in Rust when we dlopen Enzyme without dynamic_lookup on MacOS.

Although Rust’s Enzyme integration requires dynamic lookup on Apple, this should not be the default for all Apple users. This makes the behaviour opt-in while preserving existing builds.

As an alternative, we can add the non-platform-specific name ENZYME_DYNAMIC_LOOKUP, enabling it only when using Apple.
However, I think a platform-specific name is better because we can't use it on Linux or Windows either way now.

cc: @ZuseZ4

[ZuseZ4]

For context, Rust static links against llvm in our MacOS CI. Without this patch, we end up with a second copy of LLVM in libEnzyme-21.dylib. Having two copies of LLVM and passing objects between them results in bugs.
Downstream fix: eb72baf

[wsmoses]

is there any any way to test the intended use case of this here offhand?

somewhat relatedly the current rust linux tests are failing from a test editable only on the rust-lang/rust side

[ZuseZ4]

Do you want an extra rust-apple runner in this repo? Then running the apple equivalent of
nm build/x86_64-unknown-linux-gnu/enzyme/lib/libEnzyme-21.so --demangle | rg " U " | rg "llvm::" | wc -l
after the build could work. I have 843 undefined llvm symbols on my linux build. Not sure about the number of apple, but checking that we have > 100 should give plenty of error tolerance. I guess you could also search for specific llvm symbols,
undef_llvm.txt, but that might be more fragile.

[wsmoses]

yeah for sure, if rust has ci resources we can run with here to test apple that would definitely be the best route forward!

[wsmoses]

at that point I'd recommend just doing an end to end apple test, like the linux one

[ZuseZ4]

Oh that wasn't meant as an offer of Rust providing it, I don't think our infra would want to deal with covering this third party repo outside the rust-lang org. But didn't you mention that you got a lot of additional CI resources?

[wsmoses]

ah okay, and no we don't have many apple CI runners unfortunately.

Is there any other reasonable way this can be tested.

At minimum, I presume the rust tests should pass here and upstream rust CI (which runs this?). Considering the linux ones here still fail, I'm guessing thats not the case....

  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            611:  %x = alloca [4 x i8], align 4 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            612: ; call core::hint::black_box 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            613:  %0 = call float @_ZN4core4hint9black_box17hced792f2aded7be7E(float 2.000000e+00) 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            614:  store float %0, ptr %x, align 4 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            615: ; call core::hint::black_box 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            616:  %1 = call float @_ZN4core4hint9black_box17hced792f2aded7be7E(float 3.000000e+00) 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            617:  store float %1, ptr %y, align 4 
  same:163'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              .
              .
              .
  >>>>>>
  ------------------------------------------
  
  ---- [codegen] tests/codegen-llvm/autodiff/abi_handling.rs#debug stdout end ----
  
  failures:
      [codegen] tests/codegen-llvm/autodiff/abi_handling.rs#debug
  
  test result: FAILED. 10 passed; 1 failed; 0 ignored; 0 measured; 939 filtered out; finished in 205.85ms

[ZuseZ4]

Unfortunate, but then you should just merge it as is, so we can drop it from our fork.

[wsmoses]

okay I'm okay with this as is, but @ZuseZ4 @sgasho do you have an ETA on when the rust tests will be fixed (its been a few months)

[ZuseZ4]

The tests are fixed here: rust-lang/rust#151526, waiting for approval.

[wsmoses]

nice, left a comment on it!