When trying to compile any virtual/blas (either sci-libs/mkl or sci-libs/blas-reference) with sys-devel/gcc-7.3.0 and USE=hardened the ebuilds complain about a non working fortran compiler. >>> Emerging (1 of 1) sci-libs/mkl-10.0.5.025-r1::gentoo * l_mkl_p_10.0.5.025.tgz BLAKE2B SHA512 size ;-) ... [ ok ] * Checking for at least 3500 MiB disk space at "/var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/temp" ... [ ok ] * Please install currently selected gcc version with USE=fortran. * If you intend to use a different compiler then gfortran, please * set FC variable accordingly and take care that the necessary * fortran dialects are supported. * ERROR: sci-libs/mkl-10.0.5.025-r1::gentoo failed (setup phase): * Currently no working fortran compiler is available (see /var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/temp/_fortran_compile_test.log for information) * * Call stack: * ebuild.sh, line 124: Called pkg_setup * mkl-10.0.5.025-r1.ebuild, line 55: Called fortran-2_pkg_setup * fortran-2.eclass, line 280: Called _fortran-2_pkg_setup * fortran-2.eclass, line 253: Called _fortran_test_function * fortran-2.eclass, line 221: Called _fortran_die_msg * fortran-2.eclass, line 202: Called die * The specific snippet of code: * die "Currently no working fortran compiler is available (see ${T}/_fortran_compile_test.log for information)" * * If you need support, post the output of `emerge --info '=sci-libs/mkl-10.0.5.025-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=sci-libs/mkl-10.0.5.025-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/temp/die.env'. * Working directory: '/var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/homedir' * S: '/var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/work/mkl-10.0.5.025' The content of the log file is as follows: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sci-libs/mkl-10.0.5.025-r1/temp/test-fortran.f.x: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc.a(cpuinfo.o) is referenced by DSO /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status USE flags for gcc are as follows: sys-devel/gcc-7.3.0-r3:7.3.0::gentoo USE="cilk cxx fortran go graphite hardened (multilib) nls nptl objc objc++ objc-gc openmp pch pgo (pie) (ssp) vtv (-altivec) -debug -doc (-fixed-point) (-jit) (-libssp) -mpx -regression-test (-sanitize) -vanilla" The system is using also sys-devel/binutils-2.30-r4
I'm pretty sure that this is a toolchain bug hence why I'm assigning to toolchain, I'mm CCing sci though so they know about this as this will probably impact most of their fortran packages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=80600 may be related to this issue.
Can you provide build.log and emerge --info?
Hi slyfox: emerge --info: Portage 2.3.49 (python 3.6.5-final-0, hardened/linux/amd64, gcc-7.3.0, glibc-2.27-r6, 4.9.76-gentoo-r1 x86_64) ================================================================= System uname: Linux-4.9.76-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_P8700_@_2.53GHz-with-gentoo-2.4.1 KiB Mem: 8047364 total, 265508 free KiB Swap: 10483392 total, 10337512 free Timestamp of repository gentoo: Sun, 21 Oct 2018 22:45:01 +0000 Head commit of repository gentoo: 5bd19f1eebe6dd1845f8fa0987b839e7ba7f4d26 sh bash 4.4_p12 ld GNU ld (Gentoo 2.30 p5) 2.30.0 app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.24.3-r1::gentoo dev-lang/python: 2.7.15::gentoo, 3.5.5::gentoo, 3.6.5::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.38.3::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.14.1-r2::gentoo, 1.15.1-r2::gentoo sys-devel/binutils: 2.29.1-r1::gentoo, 2.30-r4::gentoo sys-devel/gcc: 6.4.0-r1::gentoo, 7.3.0-r3::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.europe.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-metamanifest: yes sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 klondike location: /usr/local/portage/local-portage masters: gentoo priority: 0 avr location: /usr/local/portage/avr masters: gentoo priority: 1 haskell location: /var/lib/layman/haskell sync-type: laymansync sync-uri: git://github.com/gentoo-haskell/gentoo-haskell.git masters: gentoo priority: 50 pentoo location: /var/lib/layman/pentoo sync-type: laymansync sync-uri: git://github.com/pentoo/pentoo-overlay.git masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA FraunhoferFDK dlj-1.1 AdobeFlash-10.3 AdobeFlash-11.x spin-commercial skype-eula skype-4.0.0.7-copyright Oracle-BCLA-JavaSE Intel-SDP Google-TOS RAR" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms sign splitdebug strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.mdfnet.se/gentoo/" LANG="es_ES.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="es es_ES en sv" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl alsa amd64 bash-completion bluray bzip2 c++0x caps cli consolekit crypt cups cxx dbus dri fam filecaps gdbm gpm handbook hardened iconv idn ipv6 kde lcms libav libnotify libtirpc mmap mmx mmxext multilib ncurses nls nptl ogg opengl openmp optimized-qmake pam pch pcre pgo pie policykit qt5 readline seccomp semantic-desktop speex sse sse2 sse3 sse4_1 ssl ssp ssse3 theora threads udev unicode urandom vdpau vorbis xattr xtpax xv zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3 sse4_1" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="es-ES en-US sv-SE es en sv" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer nlpsolver pdfimport scripting-beanshell scripting-javascript wiki-publisher" LLVM_TARGETS="BPF X86" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" QEMU_SOFTMMU_TARGETS="x86_64" RUBY_TARGETS="ruby18 ruby19 ruby21 ruby23" SANE_BACKENDS="plustek" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS build.log: * Package: sci-libs/blas-reference-20070226-r4 * Repository: gentoo * Maintainer: sci@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: network-sandbox preserve-libs sandbox splitdebug userpriv usersandbox * Please install currently selected gcc version with USE=fortran. * If you intend to use a different compiler then gfortran, please * set FC variable accordingly and take care that the necessary * fortran dialects are supported. * ERROR: sci-libs/blas-reference-20070226-r4::gentoo failed (setup phase): * Currently no working fortran compiler is available (see /var/tmp/portage/sci-libs/blas-reference-20070226-r4/temp/_fortran_compile_test.log for information) * * Call stack: * ebuild.sh, line 124: Called pkg_setup * ebuild.sh, line 371: Called fortran-2_pkg_setup * fortran-2.eclass, line 280: Called _fortran-2_pkg_setup * fortran-2.eclass, line 253: Called _fortran_test_function * fortran-2.eclass, line 221: Called _fortran_die_msg * fortran-2.eclass, line 202: Called die * The specific snippet of code: * die "Currently no working fortran compiler is available (see ${T}/_fortran_compile_test.log for information)" * * If you need support, post the output of `emerge --info '=sci-libs/blas-reference-20070226-r4::gentoo'`, * the complete build log and the output of `emerge -pqv '=sci-libs/blas-reference-20070226-r4::gentoo'`. * The complete build log is located at '/var/tmp/portage/sci-libs/blas-reference-20070226-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/blas-reference-20070226-r4/temp/die.env'. * Working directory: '/var/tmp/portage/sci-libs/blas-reference-20070226-r4/homedir' * S: '/var/tmp/portage/sci-libs/blas-reference-20070226-r4/work/lapack-lite-3.1.1' I have hunted this one down to libgfortran itself too: LANG=C ld /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so ld: warning: cannot find entry symbol _start; not setting start address /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so: undefined reference to `__cpu_model' This is not happening on another system with a similar profile though. $ LANG=C ld /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so ld: warning: cannot find entry symbol _start; not setting start address In the system where this isn't a problem I have noticed the following change in fortran related flags: FCFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" FFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" (As opossed to, on the system where the error happens) FCFLAGS="-O2 -pipe" FFLAGS="-O2 -pipe"
> CFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" > FCFLAGS="-O2 -pipe" > I have hunted this one down to libgfortran itself too: > LANG=C ld /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so > ld: warning: cannot find entry symbol _start; not setting start address > /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so: undefined reference > to `__cpu_model' That looks slightly broken. __cpu_model is supposed to be provided by libgcc_s.so via libgcc/config/i386/cpuinfo.c and normally gcc automatically appends -lgcc_s Does your libgcc_s.so.1 provide the symbol? $ nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 | fgrep cpu_model 0000000000216030 B __cpu_model You will need to debug gcc build process and find out linker options passed when libgfortran is linked. For me it's nothing special: $ xgcc -B... -B... -B... -shared -fPIC ... -shared-libgcc -Wl,-soname -Wl,libgfortran.so.5 -o .libs/libgfortran.so.5.0.0 Make sure none of those -B paths contain some outdated libgcc_s.so without __cpu_model.
Hi Slyfox! Both of the versions of libgcc_s.so.1 on the system provide the symbol: # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 | fgrep cpu_model # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/*/libgcc_s.so.1 | fgrep cpu_model 0000000000216030 B __cpu_model 0000000000216030 B __cpu_model # ls /usr/lib/gcc/x86_64-pc-linux-gnu/*/libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 So I suspect that is not the problem. I have found also that the broken system does have the symbol in the libgfortran.so whilst the one that works doesn't: broken # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so | grep __cpu U __cpu_model working # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so | grep __cpu (no output) I think this may be related to the broken system not having -march=native on the fortran compiler flags, so I'm recompiling gcc with the same flags as the working system just for the shake of it. I'll tell you tomorrow what happens then.
Okay this is weird. When gcc was on the install phase I ran nm -D /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libgfortran/.libs/libgfortran.so and the symbol was not there, but now, after reinstallation it is there again. I'm unsure how to proceed from here to fix the issue :(
(In reply to Francisco Blas Izquierdo Riera from comment #6) > Both of the versions of libgcc_s.so.1 on the system provide the symbol: > # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 | fgrep > cpu_model > # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/*/libgcc_s.so.1 | fgrep cpu_model > 0000000000216030 B __cpu_model > 0000000000216030 B __cpu_model > # ls /usr/lib/gcc/x86_64-pc-linux-gnu/*/libgcc_s.so.1 > /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 > /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 > > So I suspect that is not the problem. Just make sure you don't have an ancient copy somewhere in /usr/lib64 or /usr/local/. > I have found also that the broken > system does have the symbol in the libgfortran.so whilst the one that works > doesn't: > broken # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so | > grep __cpu > U __cpu_model > working # nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgfortran.so | > grep __cpu > (no output) What also matters is if it's linked to libgcc_s.so or not in both cases. It it fine to have 'U'-undefined symbol as long as DT_NEEDED has libgcc_s.so.1. Thus both cases can be valid (just linked dynmically and statically). The asymmetry is unexpected though. > I think this may be related to the broken system not having -march=native on > the fortran compiler flags, so I'm recompiling gcc with the same flags as > the working system just for the shake of it. Yeah, it looks related. Can you also expand your -march=native to actual flags? With something like: https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide#Expand_-march.3Dnative.2C_exact_gcc_version_and_other_system-specific_options I'll try to reproduce it in "cross-compiler" on x86_64. (In reply to Francisco Blas Izquierdo Riera from comment #7) > Okay this is weird. When gcc was on the install phase I ran nm -D > /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/ > libgfortran/.libs/libgfortran.so and the symbol was not there, but now, > after reinstallation it is there again. I'm unsure how to proceed from here > to fix the issue :( build.log should contain exact libtool call being used both times. You can try to debug what actual linker flags were passed and which files linker picked. I would just try something like LDFLAGS+=-Wl,-v
We're not the only ones to hit this. https://github.com/haikuports/haikuports/commit/b941ba5c2d1cad6721c30306de56ee541af2a0a8
https://gcc.gnu.org/PR80600 was already in gcc-7.3.0. I spent some time trying to reproduce it locally and failed. fortran gets linked correctly for me no matter what I do. Please provide full build.log for broken gcc. I'll try to find deviation from my system.
Created attachment 553588 [details] Build log
Hi slyfox, I have been reproducing this around quite reliably on this computer. The build.log will probably not help much buthere it is. The differences between using native and not are as follows: --- default.opts 2018-10-29 03:29:03.190369732 +0100 +++ native.opts 2018-10-29 03:29:31.599287715 +0100 @@ -24 +24 @@ - -march= x86-64 + -march= core2 @@ -28,2 +28,2 @@ - -mavx256-split-unaligned-load [enabled] - -mavx256-split-unaligned-store [enabled] + -mavx256-split-unaligned-load [disabled] + -mavx256-split-unaligned-store [disabled] @@ -53 +53 @@ - -mcx16 [disabled] + -mcx16 [enabled] @@ -100 +100 @@ - -mno-sse4 [enabled] + -mno-sse4 [disabled] @@ -125 +125 @@ - -msahf [disabled] + -msahf [enabled] @@ -133 +133 @@ - -msse3 [disabled] + -msse3 [enabled] @@ -135 +135 @@ - -msse4.1 [disabled] + -msse4.1 [enabled] @@ -140 +140 @@ - -mssse3 [disabled] + -mssse3 [enabled] @@ -150 +150 @@ - -mtune= generic + -mtune= core2 The machine is an old Core2Duo. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping : 10 microcode : 0xa0c cpu MHz : 2534.000 cache size : 3072 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm ida bugs : bogomips : 5053.80 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: I have been investigating the issue. What I have so far: * The library has no undefined symbols at the end of the compile phase but does at the end of the install phase. * On the rebuild stage during the install phase, the library is relinked which seems to cause the issue. If you just grep the build.log for libgfortran.so you'll find it fast. * If I use the relink command as is, I successfully trigger the issue. * The __cpu_model symbol is not versioned on the relinked .so file. * Adding -L/var/tmp/portage/sys-devel/gcc-7.3.0-r3/image//usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/ to the relink command seems to correctly bind the symbol and solve the issue. The library also works as expected after manually stripping the .so file. So I think the problem lies on a combination of: * Specific cpu flags result in some cpu checks using __cpu_model being added. * On the relink phase, libtool doesn't add /var/tmp/portage/sys-devel/gcc-7.3.0-r3/image//usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/ to the library search path. I also think the symbols is versioned on libgcc_s.so as __cpu_model@GCC_4.8.0 but I didn't see this versioning on libgfortran.so If you need me to test anything else or want me to try fixing a chroot you can ssh into for you please tell me so.
Also in case it helps, the full expansion of -march=native as it would be used on distcc (if I used it which I don't). "-march=core2" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=3072" "-mtune=core2"
(In reply to Francisco Blas Izquierdo Riera from comment #13) > Also in case it helps, the full expansion of -march=native as it would be > used on distcc (if I used it which I don't). > > "-march=core2" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a > -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm > -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-tbm > -mno-avx -mno-avx2 -mno-sse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle > -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr > -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd > -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves > -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi > -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero > -mno-pku -mno-rdpid --param "l1-cache-size=32" --param > "l1-cache-line-size=64" --param "l2-cache-size=3072" "-mtune=core2" Tried with these CFLAGS/CXXFLAGS/FCFLAGS locally and still can't get the reproducer :(. I guess I'm missing some crucial detail of the environment. Can you tarball your chroot by chance and provide it somehow? I hope to get the reproducer that way.
Does it happen on current stable gcc-8.3.0?
As 8.3.0 is stable ~everywhere let's close it as obsolete. Feel free to reopen if it still happens on gcc-8 for you.
This is still an issue with gcc 8.3.0
Can you compress sull $WORKDIR for me and place it somewhere? (maybe dev.gentoo.org space) I would try to build locally a build as close as I can match to it.
After all this time trying to find what had happened, I found that a gnat installation attempt from 2011 had seriously messed up the system. There where versions of programs like collect and cc belonging to old gcc versions all around. Similar happened with gcc libraries. After removing them and recompiling sys-devel/gcc gfortran seems to be working again. Sorry for the noise.
Just to clarify, the version of the gcc binaries the system had orphaned all around the place where for some version of gcc 4. I suspect that's why the system started failing after upgrading to gcc 7
