[SciPy-dev] Mac OS X and gcc 4.2

[Chris Kees]

On Aug 17, 2006, at 9:56 PM, David M. Cooke wrote:

> On Fri, Aug 18, 2006 at 11:46:24AM +1000, Bill Northcott wrote:
>> On 18/08/2006, at 3:00 AM, Chris Kees wrote:
>>> having trouble  even building the trunk of numpy and  scipy on Mac
>>> OS  X using a  recent build of gcc  (version 4.2.0 20060710) .
>>
>> Why use such a bleeding edge compiler?
>
> On Intel Macs, you *need* the latest for gfortran (within in the last
> several months, at least).
>
>> The FSF compilers don't even work very well on Darwin, which is only
>> of secondary interest to the FSF developers.  OTOH Apple incorporate
>> a number of Darwin optimisations into their code which does not reach
>> the FSF sources until later if at all.  Even worse current Apple
>> compilers are based on gcc-4.0.x so a lot of Apple stuff will be in
>> FSF 4.0.3 but none of it in 4.2 which is very different.
>>
>> You can use the standard Apple compilers with a Fortran from
>> hpc.sourceforge.net.  Or just get the current R 2.3.1 binary package
>> which includes gcc-4.0.3 with gfortran.  Although this appears to be
>> built from FSF sources it is universal and can target i386, ppc and
>> ppc64.
>
> Note that the gfortran from hpc.sf.net was built August 2006 -- it  
> is a
> bleeding edge compiler :)
>

I talked  to the fellow who builds  those  compilers, and  he's just   
doing  what I'm doing:  periodically building them from gcc  
development  sources with the same configuration options  I'm using.  
Up  until  recently I had  been building python too because  I  
needed  features  that  weren't yet in mac python, maybe I  need  to  
go back to that approach.  If  I built python from the same   
compilers that would eliminate  the problem below, wouldn't  it?

>>> errors with gcc 4.2:
>>>
>>> ...
>>> gcc: _configtest.c
>>> gcc: unrecognized option '-no-cpp-precomp'
>>> cc1: error: unrecognized command line option "-arch"
>>> cc1: error: unrecognized command line option "-arch"
>>> cc1: error: unrecognized command line option "-Wno-long-double"
>>
>> As others have observed the problem is the configure script.   As the
>> autoconf macro guidelines make clear one should test for features not
>> software versions.  The script clearly tests for Darwin and assumes
>> an Apple compiler.  The options causing the errors are all Apple
>> specific.
>>
>> I think the -no-cpp-precomp option is now redundant, -arch is only
>> necessary if you are trying to target a different architecture to the
>> build host.  I am surprised it is used at all.  While -Wno-long-
>> double is sort of important.  The size of long doubles has changed
>> recently on Darwin so it is useful to now if you have them in your  
>> code.
>
> The problem is these options come from the Python distutils, which is
> expecting that extensions are built with the same compiler that it was
> built with. I've run into the same problems with using gcc and Compaq
> cc on an Alpha machine :)

I'm building  numpy/scipy and  a lot  of other mixed language  code  
on mac(ppc64, ppc32,intal), compaq, sgi, linux, and cray.  In the  
past the  easiest way to make things  work has  been to build  the  
gnu compilers  from a relatively recent source. If Apple is  going   
to make their  version of  the gnu compilers incompatible with FSF  
(and  not  supply good  fortran compilers), I'm sticking with FSF.

Thanks for the help  on  this. If I can help with the distutils work,  
please  let me know.

Chris
> For numpy.distutils, we could add something for this. It's on my  
> list :D
>
> -- 
> |>|\/|<
> /--------------------------------------------------------------------- 
> -----\
> |David M. Cooke                      http:// 
> arbutus.physics.mcmaster.ca/dmc/
> |cookedm at physics.mcmaster.ca
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev