id summary reporter owner description type status priority milestone component version resolution keywords cc os architecture failure testcase blockedby blocking related differential
3565 Wrong gcc being used simonpj "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.
" bug closed high 6.12.1 Compiler 6.10.4 fixed Unknown/Multiple Unknown/Multiple