cc -c -O2 -pipe -march=native -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DNO_LAPACK -DNO_LAPACKE -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=12 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"0.3.6\" -mavx2 -DASMNAME=dgetrf -DASMFNAME=dgetrf_ -DNAME=dgetrf_ -DCNAME=dgetrf -DCHAR_NAME=\"dgetrf_\" -DCHAR_CNAME=\"dgetrf\" -DNO_AFFINITY -I.. -I. lapack/getrf.c -o dgetrf.o <command-line>: error: conflicting types for ‘dgetrf_’ lapack/getrf.c:53:5: note: in expansion of macro ‘NAME’ 53 | int NAME(blasint *M, blasint *N, FLOAT *a, blasint *ldA, blasint *ipiv, blasint *Info){ | ^~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_hardened-20190707-121727 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.1.0 * Available Python interpreters, in order of preference: [1] python3.6 [2] python2.7 (fallback) [3] pypy (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) * Available Rust versions: [1] rust-1.35.0 * [2] rust-bin-1.36.0 emerge -qpvO sci-libs/openblas [ebuild N ] sci-libs/openblas-0.3.6 USE="openmp -dynamic -eselect-ldso -pthread -serial -static-libs"
Created attachment 582538 [details] emerge-info.txt
Created attachment 582540 [details] emerge-history.txt
Created attachment 582542 [details] environment
Created attachment 582544 [details] etc.portage.tbz2
Created attachment 582546 [details] sci-libs:openblas-0.3.6:20190711-132413.log.bz2
Created attachment 582548 [details] temp.tbz2
That's strange, I have warnings about redefinitions but not errors. I will have to find what's different for you and me. I guess it could be the hardened profile.
(In reply to François Bissey from comment #7) > That's strange, I have warnings about redefinitions but not errors. I will > have to find what's different for you and me. > > I guess it could be the hardened profile. Yes, I suspect it is hardened profile. Is it possible to work out a patch?
I have no idea right now but we may want to signal upstream. They may have an idea. Does "hardened" default to treating all warnings as errors?
The hardened profile isn't much different from the default one these days, so I'm skeptical that it was a hardened issue. Regardless, I can't reproduce it now, and I suspect it was fixed by https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=64ff822f7d1 which removed a lot of junk flags from the emake commands. There's still a failing test to fix in v0.3.9, but after that I'd like to try to stabilize openblas and I'm sure we'll hit this again if I'm wrong about that commit.
