ghc: uses "gcc"

[ryandesign (Ryan Carsten Schmidt)]

ghc builds using the compiler "gcc". Ports should instead build using the compiler specified in the variable ${configure.cc} to prevent unexpected side-effects when a user has selected a nonstandard compiler using gcc_select.

[ryandesign (Ryan Carsten Schmidt)]

One side-effect of using gcc_select is documented in duplicate #19873.

[gwright@…]

Yes, this needs to be changed. The makefile probably ignores the usual environment variable, but there is a --with-gcc option. I'll give that a try.

[gwright@…]

Ugh. The ghc makefile system is OK, but the problem is in the internal cabal used to build the libraries. It ignores the top level environment variable and configure settings, and goes off scouring the PATH for plausible binaries. This will have to be fixed by patching all of the cabal configure statements. The patches are just modifications of the ones used by the cabal_configure_debug variant, but this kind of crap ought not to be happening.

[gwright@…]

r53708 should fix this.

[ryandesign (Ryan Carsten Schmidt)]

Replying to gwright@…:

there is a --with-gcc option. I'll give that a try.

Yes, I had hoped that would suffice, but when I tried it, it still got "gcc" from somewhere.

Replying to gwright@…:

r53708 should fix this.

Unfortunately I still see the problem, on Tiger/Intel.

[gwright@…]

Replying to ryandesign@…:

Replying to gwright@…:

there is a --with-gcc option. I'll give that a try.

Yes, I had hoped that would suffice, but when I tried it, it still got "gcc" from somewhere.

Replying to gwright@…:

r53708 should fix this.

Unfortunately I still see the problem, on Tiger/Intel.

Can you build with the +cabal_configure_debug variant and send (or attach) the output? On Leopard/intel r53708 fixed the problem for me (all invocations of gcc were to the specified ${configure.cc}, none to "/usr/bin/gcc"). There are only a finite number of places to patch, so it should be possible to track it down quickly.

[gwright@…]

Replying to gwright@…:

Replying to ryandesign@…:

Replying to gwright@…:

there is a --with-gcc option. I'll give that a try.

Yes, I had hoped that would suffice, but when I tried it, it still got "gcc" from somewhere.

Replying to gwright@…:

r53708 should fix this.

Unfortunately I still see the problem, on Tiger/Intel.

Can you build with the +cabal_configure_debug variant and send (or attach) the output? On Leopard/intel r53708 fixed the problem for me (all invocations of gcc were to the specified ${configure.cc}, none to "/usr/bin/gcc"). There are only a finite number of places to patch, so it should be possible to track it down quickly.

I just finished building revision 6 on Tiger/ppc and did not see any "gcc"s in the build log. If you can provide a log of the failure you saw it would be a big help.

[ryandesign (Ryan Carsten Schmidt)]

On Tiger/Intel, ghc @6.10.3_7 (with or without the +cabal_configure_debug variant) says:

checking for path to top of build tree... gcc -I. -I/mp/include -c /tmp/ghc9619_0/ghc9619_0.s -o pwd.o
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler

That's these lines in the configure script:

{ $as_echo "$as_me:$LINENO: checking for path to top of build tree" >&5
$as_echo_n "checking for path to top of build tree... " >&6; }

if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then
  cd utils/pwd
  rm -f *.o
  rm -f *.hi
  rm -f pwd
  rm -f pwd.exe
  $WithGhc -v0 --make pwd -o pwd
  cd ../..
fi

$WithGhc presumably is the ghc-bootstrap/bin/ghc binary, and I can replicate the problem myself running that command, if I set up the environment the same:

cd $(port work ghc)/ghc-6.10.3/utils/pwd
PATH=/mp/bin/no_default_gcc:/bin:/sbin:/usr/bin:/usr/sbin \
DYLD_LIBRARY_PATH=../../../ghc-bootstrap/lib:/mp/lib \
../../../ghc-bootstrap/bin/ghc -v0 --make pwd -o pwd
gcc -I. -I/mp/include -c /tmp/ghc9734_0/ghc9734_0.s -o pwd.o
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler

So ghc-bootstrap/bin/ghc is itself running "gcc". Would that maybe be fixed if this ghc bootstrap had been compiled with the --with-gcc flag pointing at the right compiler, or is there maybe a runtime switch that can be given to ghc to tell it where gcc is?

[gwright@…]

Thank you for tracking that down. There were two separate problems here. Some of the makefiles did not pass the right flags to cabal, which then searched the PATH for the first gcc that turned up. r53708 fixed that. The second problem is the one you showed, that the bootstrap compiler invokes the incorrect gcc.

Might only need to patch build.mk with the -pgmc flag. I will give it a try.

[gwright@…]

It is ugly be eventually fixable. There are a number of hand-written portfiles that invoke the bootstrap or new ghc with inconsistent options. These all have to be patched.

Will take a few days.

[gwright@…]

Fixed in r56583. As I mentioned, the fix was ugly. Now that all of the files that need to be patched are known, I will try to get this fixed upstream.