Wrong gcc being used

SimonM and I have just spent two hours tracking down a horrible gcc-related problem.

The current story is that we ship GHC complete with a Mingw gcc. Nowadays we go further, and put a Mingw installation into the GHC repo, so that someone building GHC doesn't need to download Mingw. This is good.

The problem is this. The configure script includes

AC_CHECK_FUNCS(__mingw_vfprintf)

It turns out that this check

• Should say "no" with the Mingw stuff in the current GHC repo
• But actually says "yes"

Because of the wrong answer, compilation of Linker.c in the RTS fails with

rts\Linker.c:904:0:
     error: `__mingw_vfprintf' undeclared here (not in a function)

Why is the answer wrong? Because:

• The test correctly invokes c:/code/HEAD/inplace/mingw/bin/gcc.exe; ie the one in the tree
• But, when linking, that gcc looks in /mingw/lib, where I just happen to have a (different) Mingw blob of files. That makes the link succeed when it should fail.

Here's an example. Here is foo.c:

char __mingw_vfprintf ();

char (*f) () = __mingw_vfprintf;

int main () { return 0; }

Now watch:

bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe   foo.c 
bash-3.1$ mv c:/mingw c:/mingw-save
bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe   foo.c 
C:/DOCUME~1/simonpj/LOCALS~1/Temp/ccuJ4q8y.o:foo.c:(.data+0x0): undefined reference to `__mingw_vfprintf'
collect2: ld returned 1 exit status

Moving c:/mingw out of the way changes the behaviour!!!

If you give a -B flag you can make it behave more predictably:

bash-3.1$ mv c:/mingw-save c:/mingw
bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe   foo.c -Bc:/code/HEAD/inplace/mingw/lib
C:/DOCUME~1/simonpj/LOCALS~1/Temp/ccuJ4q8y.o:foo.c:(.data+0x0): undefined reference to `__mingw_vfprintf'
collect2: ld returned 1 exit status

That is, even with c:/mingw existing, the -B flag makes it do the right thing.

Mind you, if you add -v you'll see that there are still references to /mingw, so it's still not really right.

So far as we can see, the path "/mingw" is hard-wired into gcc.exe.

It's not clear how to fix this. Probably the easiest path is to build a shim for gcc.exe, which lives in the same directory as ghc.exe, and which simply invokes the real gcc adding the -B flag. Fixing it is urgent for 6.12. If GHC 6.12 invokes gcc without passing a -B flag (and without a shim) we may link against libraries that happen randomly to be on the user's machine, rather than against the libraries that come with GHC.

Trac metadata

Trac field	Value
Version	6.10.4
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture