Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
rgommers opened this issue Feb 22, 2022 · 3 comments · May be fixed by #118
Open

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

rgommers opened this issue Feb 22, 2022 · 3 comments · May be fixed by #118

Comments

@rgommers
Copy link

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.
@rgommers rgommers mentioned this issue Feb 22, 2022
Closed
1 task
@erykoff
Copy link
Contributor

erykoff commented Feb 22, 2022

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 erykoff linked a pull request Feb 25, 2022 that will close this issue
Open
@erykoff
Copy link
Contributor

erykoff commented Feb 25, 2022

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
Copy link
Contributor

isuruf commented Apr 21, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Turn off outputIsMappableFile when building to osx-arm64 erykoff/cctools-port
3 participants
@rgommers @erykoff @isuruf