#3565: Wrong gcc being used
-------------------------------+--------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.12.1
Component: Compiler | Version: 6.10.4
Severity: normal | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------+--------------------------------------------
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3565>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
