[MacPorts] #15878: mftrace 1.2.14 failing build

[MacPorts]

#15878: mftrace 1.2.14 failing build
----------------------------------+-----------------------------------------
  Reporter:  hashashin at gmail.com  |       Owner:  macports-tickets at lists.macosforge.org
      Type:  defect               |      Status:  new                                  
  Priority:  Normal               |   Milestone:  Port Bugs                            
 Component:  ports                |     Version:  1.6.0                                
Resolution:                       |    Keywords:  mftrace                              
----------------------------------+-----------------------------------------
Changes (by ryandesign at macports.org):

 * cc: ryandesign at macports.org (added)

Comment:

 Confirmed with Mac OS X 10.5.4, Xcode 3.1, MacPorts from trunk, on a
 MacBook Pro.

 Workaround: run "`sudo port install mftrace`" again. It works the second
 time.

 The first time, it tries to run the command "`Wall -O2 -I.    gf2pbm.c
 -o gf2pbm`" which makes no sense. "`-Wall -O2 -I.`" are the CFLAGS defined
 in the GNUmakefile that are supposed to be sent to the C compiler. But the
 C compiler name and the hyphen before "Wall" are missing for some reason.
 MacPorts is setting the CC environment variable to /usr/bin/gcc-4.0 during
 the configure phase, and the configure script is seeing it, but this
 message is apparently not getting to the build phase for some reason.
 Because you are on a case-insensitive file system, the OS tries to execute
 the totally unrelated program `/usr/bin/wall` which does not have a -O
 option so we get the error message "`Wall: illegal option -- O`".

 The second time we run the install (which picks up at the destroot phase),
 it uses the command "`cc -Wall -O2 -I.    gf2pbm.c   -o gf2pbm`" which is
 better. For some reason it knows the C compiler's name the second time and
 the installation can finish. Note that it's using `cc` and not
 `/usr/bin/gcc-4.0`. Maybe the reason it succeeds the second time has
 something to do with the fact that MacPorts is not attempting to set the
 CC environment variable since we're in the destroot phase where that value
 shouldn't be needed.

-- 
Ticket URL: <http://trac.macports.org/ticket/15878#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS