Using compilers with `-o absolute-path/to/target` is broken for recent cctools
rgommers opened this issue · comments
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 conda-forge/cctools-and-ld64-feedstock#50 (comment) @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.
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.
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.
correct way to fix this would be to invalidate the cache created at mmap
time.
See llvm/llvm-project@151990dd94e5#diff-eae7124ad4cf8f57aabf7930d1331ffa55b48f0ca975f5e963e7c2e5c0b65fedR930-R942