Bug 169262 - dev-python/numpy-1.0.1-r1 doesn't respect CFLAGS
|
Bug#:
169262
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: bicatali@gentoo.org
|
Reported By: James@superbug.demon.co.uk
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: dev-python/numpy-1.0.1-r1 doesn't respect CFLAGS
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-03-04 10:57 0000
|
Here is some output from the make process:
compiling Fortran sources
Fortran f77 compiler: /usr/bin/gfortran -Wall -ffixed-form
-fno-second-underscore -fPIC -O -Wall -O0 -g -Wall -O0 -g -mno-sse3
-DBIGSYM=1 -fPIC -march=i486 -DPACKAGE_NAME=wsjt -DPACKAGE_TARNAME=wsjt
-DPACKAGE_VERSION=5.9.6 -DPACKAGE_STRING=wsjt\ 5.9.6
-DPACKAGE_BUGREPORT= -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_ERRNO_H=1 -DHAVE_SYS_SYSLOG_H=1 -DHAVE_STDDEF_H=1
-DHAVE_LIBGEN_H=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_WAIT_H=1 -DHAVE_STDIO_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_LINUX_PPDEV_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1
-DTIME_WITH_SYS_TIME=1 -DSTRING_WITH_STRINGS=1 -DSIZEOF_INT64_T=8
-DSIZEOF_LONG_LONG=8 -DNDEBUG=1 -DPREFIX=/usr/local/
-DFC_LIB_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/
-DFC=/usr/bin/gfortran -DUSE_ALSA=1 -DHAS_ASOUNDLIB_H=1
-DHAS_SOUNDCARD_H=1 -DHAS_JACK_H=1 -DHAS_SAMPLERATE_H=1
-fno-second-underscore -march=nocona -mmmx -msse2 -msse -fomit-frame-pointer
Fortran f90 compiler: /usr/bin/gfortran -Wall -fno-second-underscore
-fPIC -O -Wall -O0 -g -Wall -O0 -g -mno-sse3 -DBIGSYM=1 -fPIC
-march=i486 -DPACKAGE_NAME=wsjt -DPACKAGE_TARNAME=wsjt
-DPACKAGE_VERSION=5.9.6 -DPACKAGE_STRING=wsjt\ 5.9.6
-DPACKAGE_BUGREPORT= -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_ERRNO_H=1 -DHAVE_SYS_SYSLOG_H=1 -DHAVE_STDDEF_H=1
-DHAVE_LIBGEN_H=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_WAIT_H=1 -DHAVE_STDIO_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_LINUX_PPDEV_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1
-DTIME_WITH_SYS_TIME=1 -DSTRING_WITH_STRINGS=1 -DSIZEOF_INT64_T=8
-DSIZEOF_LONG_LONG=8 -DNDEBUG=1 -DPREFIX=/usr/local/
-DFC_LIB_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/
-DFC=/usr/bin/gfortran -DUSE_ALSA=1 -DHAS_ASOUNDLIB_H=1
-DHAS_SOUNDCARD_H=1 -DHAS_JACK_H=1 -DHAS_SAMPLERATE_H=1
-fno-second-underscore -march=nocona -mmmx -msse2 -msse -fomit-frame-pointer
Fortran fix compiler: /usr/bin/gfortran -Wall -ffixed-form
-fno-second-underscore -Wall -fno-second-underscore -fPIC -O -Wall -O0
-g -Wall -O0 -g -mno-sse3 -DBIGSYM=1 -fPIC -march=i486
-DPACKAGE_NAME=wsjt -DPACKAGE_TARNAME=wsjt -DPACKAGE_VERSION=5.9.6
-DPACKAGE_STRING=wsjt\ 5.9.6 -DPACKAGE_BUGREPORT= -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_SYS_RESOURCE_H=1
-DHAVE_SYS_PARAM_H=1 -DHAVE_ERRNO_H=1 -DHAVE_SYS_SYSLOG_H=1
-DHAVE_STDDEF_H=1 -DHAVE_LIBGEN_H=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_WAIT_H=1
-DHAVE_STDIO_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_SYS_RESOURCE_H=1
-DHAVE_LINUX_PPDEV_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_FCNTL_H=1
-DHAVE_SYS_IOCTL_H=1 -DTIME_WITH_SYS_TIME=1 -DSTRING_WITH_STRINGS=1
-DSIZEOF_INT64_T=8 -DSIZEOF_LONG_LONG=8 -DNDEBUG=1 -DPREFIX=/usr/local/
-DFC_LIB_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/
-DFC=/usr/bin/gfortran -DUSE_ALSA=1 -DHAS_ASOUNDLIB_H=1
-DHAS_SOUNDCARD_H=1 -DHAS_JACK_H=1 -DHAS_SAMPLERATE_H=1
-fno-second-underscore -march=nocona -mmmx -msse2 -msse -fomit-frame-pointer
Notice that I try to add -mno-sse3 and -march=i486
but fortran seems to automatically add it all back in again.
See the -march=nocona
There is no mention of nocona in the Makefile.
I have an pentium4 CPU without sse3 support.
I don't have the sse3 instruction, i.e. Not a nocona arch.
Does anyone know how to get fortran to stop using -march=nocona?
The sse3 instructions being generated are all:
fisttpl 0x17c(%esp)
I.e. the fisttpl instruction.
Reproducible: Always
After editing the following file:
/usr/lib/python2.4/site-packages/numpy/distutils/fcompiler/gnu.py
with this diff
--- gnu.py.old 2007-03-04 11:08:43.000000000 +0000
+++ gnu.py 2007-03-04 11:13:41.000000000 +0000
@@ -192,7 +192,7 @@
march_opt = '-march=athlon-mp'
# there's also: athlon-tbird, athlon-4, athlon-xp
elif cpu.is_Nocona():
- march_opt = '-march=nocona'
+ march_opt = '-march=pentium4'
elif cpu.is_Prescott():
march_opt = '-march=prescott'
elif cpu.is_PentiumIV():
My program works again, and the -march=pentium4 is used.
I conclude therefore, that the nocona cpu.is_Nocona() function is wrong.
I suggest maybe a better fix would be to file:
/usr/lib/python2.4/site-packages/numpy/distutils/cpuinfo.py
As nocona enables sse3 instructions for nocona, we should do a check for sse3
in the _is_Nocona test routine.
--- cpuinfo.py.old 2007-03-04 11:26:20.000000000 +0000
+++ cpuinfo.py 2007-03-04 11:25:14.000000000 +0000
@@ -185,7 +185,7 @@
return self.is_PentiumIV() and self.has_sse3()
def _is_Nocona(self):
- return self.is_PentiumIV() and self.is_64bit()
+ return self.is_PentiumIV() and self.is_64bit() and self.has_sse3()
def _is_Itanium(self):
return re.match(r'.*?Itanium\b',
Which ebuild is this about? Definitely NOT gcc.
Ah! Sorry, if mentioned gfortran, and that is contained in gcc, so I thought it
was gcc.
It is actually:
dev-python/numpy-1.0.1-r1
bicatali: please take care offensichtlich this and set either yourself or the
science herd as maintainer.
Thanks for reporting.
Should be fixed now with an upstream patch, please re-open if it persists.