Opened 15 years ago

Closed 15 years ago

#19856 closed defect (fixed)

ghc: uses "gcc"

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: gwright@…
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: Cc:
Port: ghc

Description

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.

Change History (11)

comment:1 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:2 Changed 15 years ago by gwright@…

Status: newassigned

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.

comment:3 Changed 15 years ago by 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.

comment:4 Changed 15 years ago by gwright@…

r53708 should fix this.

comment:5 in reply to:  2 ; Changed 15 years ago by 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.

comment:6 in reply to:  5 ; Changed 15 years ago by 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.

comment:7 in reply to:  6 Changed 15 years ago by 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.

comment:8 Changed 15 years ago by 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?

comment:9 Changed 15 years ago by 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.

comment:10 Changed 15 years ago by 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.

comment:11 Changed 15 years ago by gwright@…

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.