Keno
commented
1 year ago 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.
While looking at the error rebuilding SuiteSparse in https://github.com/JuliaPackaging/Yggdrasil/pull/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=memoryadded 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=memoryflag 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).