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

New issue

Open

opened 2022-02-22 08:56:38 -06:00 by rgommers · 3 comments

rgommers commented

2022-02-22 08:56:38 -06:00

(Migrated from github.com)

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.

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`: ```fortran 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 commented

2022-02-22 09:49:06 -06:00

(Migrated from github.com)

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.

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 commented

2022-02-24 23:22:52 -06:00

(Migrated from github.com)

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.

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 commented

2022-04-21 14:43:31 -05:00

(Migrated from github.com)

correct way to fix this would be to invalidate the cache created at mmap time.
See github.com/llvm/llvm-project@151990dd94 (diff-eae7124ad4)

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