Using compilers with `-o absolute-path/to/target` is broken for recent cctools

[rgommers]

With the latest build of cctools in conda-forge, using Clang or GFortran with an absolute path to the output target results in a broken binary.

Here is a simple reproducer for Fortran code. With a test file sanitycheckf.f90:

program main; print *, "Fortran compilation is working."; end program

And using the arm64-apple-darwin20.0.0-gfortran compiler, I see the following on an arm64 Macbook:

% rm sanitycheckf
% gfortran build/meson-private/sanitycheckf.f90 -o /Users/rgommers/code/scipy/sanitycheckf       
% ./sanitycheckf 
zsh: killed     ./sanitycheckf
% rm sanitycheckf
% gfortran build/meson-private/sanitycheckf.f90 -o sanitycheckf 
% ./sanitycheckf                                              
 Fortran compilation is working.

Showing that a simple absolute path is enough to trigger the problem.

On https://github.com/conda-forge/cctools-and-ld64-feedstock/issues/50#issuecomment-1047433827 @erykoff observed the same issue with a hello world C program and Clang.

Copying the produced binary (cp sanitycheckf sanitycheckf2 && cp sanitycheckf2 sanitycheckf) makes the problem go away. Downgrading to an older cctools version also made the problem go away.

[erykoff]

Just to be clear, my test with clang was a symlink to arm64-apple-darwin0.0.0-clang from conda-forge. But it seems that the problem is not the compiler, but the ld64 linker as @rgommers points out on the feedstock issue that downgrading ld64 specifically fixes the problem.

[erykoff]

See #118, but the problem is triggered when mmap is used which is triggered when either (a) the output file exists (but is deleted!) or (b) a path (relative or absolute) is specified. I tested this and everything seems to work fine.

[isuruf]

correct way to fix this would be to invalidate the cache created at mmap time. See https://github.com/llvm/llvm-project/commit/151990dd94e5#diff-eae7124ad4cf8f57aabf7930d1331ffa55b48f0ca975f5e963e7c2e5c0b65fedR930-R942