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 |