Created attachment 522922 [details] build.log configure: error: A BLAS library was detected but found incompatible with your Fortran 77 compiler settings. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sci-mathematics/octave-4.2.1/work/octave-4.2.1/config.log [31;01m*[0m ERROR: sci-mathematics/octave-4.2.1::gentoo failed (configure phase): [31;01m*[0m econf failed [31;01m*[0m [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 124: Called src_configure [31;01m*[0m environment, line 4671: Called econf '--localstatedir=/var/state/octave' '--with-blas=-lblas' '--with-lapack=-llapack -lblas' '--disable-64' '--disable-jit' '--enable-shared' '--with-z' '--with-bz2' '--without-OSMesa' '--disable-static' '--disable-docs' '--disable-java' '--enable-readline' '--without-curl' '--without-fftw3' '--without-fftw3f' '--disable-fftw-threads' '--with-glpk' '--without-hdf5' '--with-magick=ImageMagick' '--with-opengl' '--with-fltk' '--without-openssl' '--without-portaudio' '--with-qhull' '--with-qrupdate' '--without-qt' '--without-sndfile' '--with-arpack' '--with-umfpack' '--with-colamd' '--with-ccolamd' '--with-cholmod' '--with-cxsparse' '--with-x' [31;01m*[0m phase-helpers.sh, line 666: Called __helpers_die 'econf failed' [31;01m*[0m isolated-functions.sh, line 117: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m die "$@" [31;01m*[0m
Created attachment 522924 [details] emerge --info output
Comment on attachment 522922 [details] build.log !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sci-mathematics/octave-4.2.1/work/octave-4.2.1/config.log Yes?
gcc-7 strikes again. I think we will find that blas is linked to libgfortran.so.3 when gfortran-7 wants to link to libgfortran.so.4.
Created attachment 523846 [details] config.log Attaching the config log, sorry for the delay.
Exactly what I thought: configure:38799: x86_64-pc-linux-gnu-gcc -o conftest -march=native -O2 -pipe -pthread -fopenmp -Wl,-O1 -Wl,--as-needed -Wl,-z,defs conftest.c -lblas -lm -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../.. -lgfortran -lm -lquadmath >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libgfortran.so.3, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_stop_string@GFORTRAN_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_string_len_trim@GFORTRAN_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_st_write@GFORTRAN_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_st_write_done@GFORTRAN_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_transfer_character_write@GFORTRAN_1.4' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/libblas.so: undefined reference to `_gfortran_transfer_integer_write@GFORTRAN_1.4' collect2: error: ld returned 1 exit status blas and lapack and then all their dependencies needs rebuilding with the new compiler.
I was hit by this as well, so I can confirm (mostly stable amd64). (In reply to François Bissey from comment #5) > blas and lapack and then all their dependencies needs rebuilding with the > new compiler. I did 1. emerge -1qva blas-reference lapack-reference 2. revdep-rebuild -- -1qva which emerged arpack, qrupdate, scipy, hdf5, and finally octave without issues for me.
Same error with octave-4.2.2 emerge -1qva blas-reference lapack-reference did help.
(In reply to Masn6n0 from comment #7) > Same error with octave-4.2.2 > > emerge -1qva blas-reference lapack-reference > > did help. So do I
Not reproducible anymore with newer GCC (8 and higher) and Octave 5.x versions
Thanks for checking back, will cleanup old.