Created attachment 563344 [details] build.log Interesting lines from build log: Could not locate executable x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -shared ... C compiler: x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -O2 -pipe -march=native -fno-strict-aliasing -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/include/python2.7 -c' x86_64-pc-linux-gnu-gcc: _configtest.c failure. removing: _configtest.c _configtest.o Traceback (most recent call last): File "setup.py", line 394, in <module> setup_package() File "setup.py", line 386, in setup_package setup(**metadata) File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/core.py", line 169, in setup return old_setup(**new_attr) File "/usr/lib64/python2.7/site-packages/setuptools/__init__.py", line 129, in setup return distutils.core.setup(**attrs) File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/command/build.py", line 47, in run old_build.run(self) File "/usr/lib64/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/command/build_src.py", line 148, in run self.build_sources() File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/command/build_src.py", line 159, in build_sources self.build_library_sources(*libname_info) File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/command/build_src.py", line 294, in build_library_sources sources = self.generate_sources(sources, (lib_name, build_info)) File "/var/tmp/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5/numpy/distutils/command/build_src.py", line 377, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 675, in get_mathlib_info raise RuntimeError("Broken toolchain: cannot link a simple C program") RuntimeError: Broken toolchain: cannot link a simple C program
Created attachment 563346 [details] emerge --info
I've got the same problem blocking amd64-fbsd keywordreqs.
I think the following bits may be more relevant Found executable /usr/bin/gfortran Could not locate executable x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -shared and don't know how to compile Fortran code on platform 'posix' C compiler: x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -O2 -pipe -march=native -fno-strict-aliasing -fPIC python build logs can be so useless.
1.13.3 is apparently the first broken Gentoo version.
That's what a successful run looks like: ====================================================================== building py_modules sources creating /dev/shm/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5-python2_7/src.linux-x86_64-2.7 creating /dev/shm/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5-python2_7/src.linux-x86_64-2.7/numpy creating /dev/shm/portage/dev-python/numpy-1.14.5/work/numpy-1.14.5-python2_7/src.linux-x86_64-2.7/numpy/distutils building library "npymath" sources get_default_fcompiler: matching types: '['gnu95', 'intel', 'lahey', 'pg', 'absoft', 'nag', 'vast', 'compaq', 'intele', 'intelem', 'gnu', 'g95', 'pathf95', 'nagfor']' customize Gnu95FCompiler Found executable /usr/bin/gfortran Could not locate executable x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -shared Found executable /usr/bin/x86_64-pc-linux-gnu-ar customize Gnu95FCompiler customize Gnu95FCompiler using config C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -march=native -O2 -pipe -fno-strict-aliasing -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/include/python2.7 -c' x86_64-pc-linux-gnu-gcc: _configtest.c x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -march=native -O2 -pipe -fno-strict-aliasing -fPIC ============================================================ Note how it didn't chase for any other compiler after finding gfortran? What I think is happening is that the build script cannot compiled a mixed source C/Fortran program or a fortran program. If you don't use lapack as in your case some internal fortran code needs to be compiled and linked against. Which means that even if you don't use lapack you need a working fortran compiler. The build log suggests you don't have one or that the way numpy tries to use it is broken.
In short I think the line FORTRAN_NEEDED=lapack at the top of the numpy ebuild is a lie. You always need a fortran compiler.
OK so I did a better checking of a build with "-lapack" and a fortran compiler is not used, the lapack bits needed by numpy looks like prepacked f2c code. But there must be something at the beginning of the setup that fails fortran detection for you guys. If fortran is not needed that code must be allowed to softly fail.
Darn. Fortran was definitely a red herring. I thought there was something related to Fortran happening but it is not the case. I have no idea what is causing the failure on your setup and cannot find a way of reproducing it so far.
Created attachment 571022 [details] numpy-1.14.5 build log Still happening with numpy-1.14.5
Created attachment 571024 [details] numpy-1.14.5 build log with "x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -shared" shell script in path Just for a laugh, I created "x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -shared" as a shell script with suitable contents and tried again, this time it doesn't complain about not finding it, but still crashes. Should I enable gfortran and find out if it's somehow become a hard dependency without anyone noticing?
Turns out I already have fortran enabled, did some googling and https://github.com/numpy/numpy/pull/12831 may be relevant - trying numpy-1.16.1 which succeeds. Apparently this issue only affects the stable version, what's the best way to deal with that? bump stable version, backport a fix?
Hum, that pull is only supposed to fix problem with intel compiler and apparently fix a problem introduced in numpy-1.16.0.rc1. While it is interesting that the latest numpy works, I suspect the problem is elsewhere.
By the way, is the problem also found in 1.15.4?
(In reply to François Bissey from comment #13) > By the way, is the problem also found in 1.15.4? I jumped straight from stable (1.14.5) to unstable (1.16.1) Checking now however, neither 1.15 nor 1.14 throws that error (via ebuild blah install) - could it be caused by something weird in the older version of numpy? However, 1.14 dies after a while with '/bin/bash: /usr/local/bin/x86_64-pc-linux-gnu-gcc: No such file or directory' - I guess it's inconsistent about processing spaces in the compiler executable name, since I had to create "/usr/local/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native" to get past earlier parts of the install. If I remove that, even 1.14.5 seems fine now, what an odd heisenbug!
