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.

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

Fortran compilation not working on MSAN Platform #289

Open
imciner2 opened this issue Dec 29, 2022 · 1 comment
Open

Fortran compilation not working on MSAN Platform #289

imciner2 opened this issue Dec 29, 2022 · 1 comment

Comments

@imciner2
Copy link
Member

While looking at the error rebuilding SuiteSparse in JuliaPackaging/Yggdrasil#6006, I discovered that the MSAN platform seems to not be properly setting up the Fortran compiler in the builder.

Currently, the builder is configured to always use gfortran as the fortran compiler, no matter the platform. This is a problem because none of the GNU/GCC compilers actually support MSAN (they support ASAN, but not MSAN, see the note in https://developers.redhat.com/blog/2021/05/05/memory-error-checking-in-c-and-c-comparing-sanitizers-and-valgrind that mentions it is only a clang option). This means the compiler and linker flags get -fsanitize=memory added to them, which causes gfortran to error on an unknown argument (and fail compilation).

There are two ways to fix this from what I can see:

  1. Simply remove the -fsanitize=memory flag generation from the gfortran compiler path, letting the MSAN platform compile code using gfortran without error.
  2. Add the ability to use flang in the runner to compile fortran code and have it prefer flang when building with sanitizer support.

(2) is more involved since it requires ensuring the compiler is properly plumbed in and available, but it is also the one that is probably preferred (that way the fortran is actually compiled with MSAN support as well).

@Keno
Copy link
Contributor

Keno commented Dec 29, 2022

The current way we're doing msan support for fortran dependencies is using flang. See
https://github.com/JuliaPackaging/Yggdrasil/blob/master/O/OpenBLAS/common.jl#L66-L83
It adds a bunch of boiler plate to every build though, so it's only done on a case-by-case basis. I think the longer-term plan is to wait until new-flang is mature enough and then just build that into the base image. Since suitesparse is a base dependency, it would be good to have it, but if it gets in the way, I think it's ok to ignore for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants