build does not respect --with-gcc option

[gwright]

The build still does not respect the --with-gcc option, despite the patches that closed #2966.

To reproduce on OS X: replace gcc, which is a symlink to the actual compiler, with a symlink to a script that errors out:

#!/bin/bash
echo "Uh oh.  You shouldn't be here!"
exit 1

Then run

gwright-macbook> ./configure --with-gcc=/usr/bin/gcc-4.2
gwright-macbook> make

where /usr/bin/gcc-4.2 is the actual gcc binary.

The build fails with:

ghc-prim-0.2.0.0: cannot find libHSghc-prim-0.2.0.0.a on library path (ignoring)
"inplace/bin/ghc-cabal" configure --with-ghc="/Users/gwright/tmp/ghc-7-branch/ghc/inplace/bin/dummy-ghc" --with-ghc-pkg="/Users/gwright/tmp/ghc-7-branch/ghc/inplace/bin/ghc-pkg" --with-gcc="/usr/bin/gcc-4.2" --configure-option=--with-cc="/usr/bin/gcc-4.2"  --enable-library-profiling --enable-library-for-ghci --configure-option=CFLAGS=" -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fno-stack-protector  " --configure-option=LDFLAGS=" -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5  " --configure-option=CPPFLAGS=" @CONF_CPP_OPTS_STAGE1@  " -- dist-install libraries/integer-gmp
Configuring integer-gmp-0.2.0.2...
checking build system type... i386-apple-darwin10.5.0
checking host system type... i386-apple-darwin10.5.0
checking target system type... i386-apple-darwin10.5.0
checking for gcc... /usr/bin/gcc-4.2
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[1]: *** [libraries/integer-gmp/dist-install/package-data.mk] Error 77
make: *** [all] Error 2

From the configure output, we can see that sometimes the specified compiler is found, but other times /usr/bin/gcc is picked off the PATH, in violation of your mother's rule, "Don't put that in your mouth, you don't know where it's been."

I've been able to get the build to complete with /usr/bin/gcc linked to the above script by patching aclocal.m4, compiler/Makefile.local and rts/ghc.mk, as well as passing

SRC_HC_OPTS += -pgmP /usr/bin/gcc-4.2 -optP-E -optP-undef -optP-traditional
SRC_HC_OPTS += -pgma /usr/bin/gcc-4.2
SRC_HC_OPTS += -pgmc /usr/bin/gcc-4.2
SRC_HC_OPTS += -pgml /usr/bin/gcc-4.2

in build.mk.

What I've done is unlikely a minimal fix. If the -pgmX options shouldn't be passed through SRC_HC_OPTS, I probably need to make a lot of fiddly changes. On the other hand, if we do allow passing the -pgmX options through SRC_HC_OPTS, we run into the problem in ticket #4821, which is has a kludgy solution.

Should the SRC_HC_OPTS be left alone and the path to the compiler be passed other ways?

[simonmar]

We should fix --with-gcc. It can't be entirely broken, because we use the same mechanisms on Windows to use the inplace mingw gcc, and I'm fairly sure at least on some of my machines I don't have mingw installed in the usual place.

Using SRC_HC_OPTS is probably not the right thing, because those options will be passed to the bootstrap compiler too. That would normally be a strange thing to do, because the bootstrap compiler is supposed to generate working executables by itself, with no special options.

[gwright]

Replying to simonmar:

We should fix --with-gcc. It can't be entirely broken, because we use the same mechanisms on Windows to use the inplace mingw gcc, and I'm fairly sure at least on some of my machines I don't have mingw installed in the usual place.

Yes, the --with-gcc option mostly works but there are a few places where it fails.

Using SRC_HC_OPTS is probably not the right thing, because those options will be passed to the bootstrap compiler too. That would normally be a strange thing to do, because the bootstrap compiler is supposed to generate working executables by itself, with no special options.

OK, I'll patch so that it's not necessary to mess with SRC_HC_OPTS. This does set an implicit policy, i.e., that the options to substitute preprocessors/compilers/assembers/linker shouldn't be used when building ghc. I've no problem with that, but it should probably be written down on the wiki. Perhaps just saying that switching compilers should be done with the --with-gcc option only, and if you needed to set anything else, it's a bug and should be reported.

You can close #4821 as invalid and point people to this bug instead. If SRC_HC_OPTS should never have a -pgmP option, we won't have a conflict between the makefile supplied preprocessor options and any explicit ones.

[gwright]

I've started to work on this.

[gwright]

Someone else seems to have fixed the original bug reported in this ticker. But in the words of Yoda, "There is another."

The remaining bug only occurs on OS X. Apple's dtrace uses /usr/bin/gcc as its default preprocessor. If /usr/bin/gcc isn't the gcc you want, you need to pass the correct gcc through the cpppath option. (Yes, this is a bit odd looking.)

The attached patch fixes this. I edited validate to pass --with-gcc=/usr/bin/gcc-4.2 to configure, pointed /usr/bin/gcc to the no_gcc script above. sh validate ran to completion.

If the patch is applied, this ticket can be closed.

[igloo]

Thanks for the patch!

To be merged:

Tue Dec 21 05:32:33 PST 2010  gwright@antiope.com
  * Fix #4829 (build does not respect --with-gcc option)

[igloo]

Merged.