Skip to content

Configuring C compiler and linker flags separately breaks cabal (and potentially other downstream)

Cabal has the following logic which combines together the C compiler flags for the linker and C compiler flags. This isn't safe to do in general because the flags might not be accepted by both modes.

 63 (ccProg, ccFlags) <- configureCCompiler verbosity programDb 
 64   ccProgShort <- getShortPathName ccProg                                        
 65   -- The C compiler's compilation and linker flags (e.g.                        
 66   -- "C compiler flags" and "Gcc Linker flags" from GHC) have already           
 67   -- been merged into ccFlags, so we set both CFLAGS and LDFLAGS                
 68   -- to ccFlags    

As our configure script now checks more precisely whether a flag is accepted by the C compiler used normally or the C compiler used as a linker.. this combination logic is problematic.

I am beginning to wonder whether this approach is very wise at all, because there's no similar convention to CFLAGS to pass flags into configure scripts for use with the C compiler when used as a linker.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information