[MacPorts] #28966: py27-numpy @1.5.1 +python build failure: library not found for -lgfortranbegin

[MacPorts]

#28966: py27-numpy @1.5.1 +python build failure: library not found for
-lgfortranbegin
---------------------------------+------------------------------------------
 Reporter:  everbloom@…          |       Owner:  ram@…                
     Type:  defect               |      Status:  new                  
 Priority:  Normal               |   Milestone:                       
Component:  ports                |     Version:  1.9.2                
 Keywords:                       |        Port:  py26-numpy py27-numpy
---------------------------------+------------------------------------------

Comment(by everbloom@…):

 Replying to [comment:3 blb@…]:
 > Replying to [comment:2 everbloom@…]:
 > > According to itself, /usr/bin/gfortran is GNU Fortran (GCC) 4.2.1
 (Apple Inc. build 5659) + GF 4.2.4. So I guess it came with Xcode and
 Apple's gcc install.
 >
 > Is that Xcode 4?  If so, maybe Apple is including a fortran compiler
 now...
 Just Xcode 3.x, so I don't know how I got an Apple gfortran! I'm more
 likely to have the build that R tools come with.
 >
 > >
 > > {{{whereis gfortran}}} tells me about the /usr/bin/gfortran as well.
 However, in /opt/local/bin there's a {{{gfortran-mp-4.4}}} which I guess
 is the macports gfortran. Is there a significant difference between
 macports gfortran and apple gfortran? Why is the port trying to use a non-
 mp version?
 >
 > That's a good question, the Portfile appears to be trying to use the
 MacPorts' one, but looks like numpy's build setup may be ignoring what the
 Portfile says.
 Buggery.

 To my amazement, renaming /usr/bin/gfortran to /usr/bin/not-gfortran seems
 to have forced it to use mp's gfortran and it installed fine. That's
 *weird*, and not very nice of numpy to pick its own gfortran :(.

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