Re: [SciPy-dev] Mac OS X and gcc 4.2
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? 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.
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. Bill Northcott
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 :)
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 :) 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@physics.mcmaster.ca
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@physics.mcmaster.ca _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
participants (3)
-
Bill Northcott -
Chris Kees -
David M. Cooke