[solved] C compiler cannot create executables

[forrestfunk81]

Nach längerer Abwesenheit wollte ich auf meinem Router Updates einspielen. Da kamen ein paar Hundert Updates zusammen und leider ist der Build abgebrochen, da /var/tmp/portage vollgelaufen ist. Jetzt kann ich nichts meher bauen, da das System in einem inkonsistentem Zustand ist. Egal was ich baue ich bekomme immer den Fehler

Code: Select all

configure: error: C compiler cannot create executables

Glibc kann ich nicht neu bauen, weil es gerne eine neuere Version der sys-kernel/linux-headers hätte. Und wenn ich die linux-headers aktualisieren will, finde ich noch folgende Zeile:

Code: Select all

/usr/libexec/gcc/x86_64-pc-linux-gnu/11/cc1: symbol lookup error: /usr/lib64/libmpfr.so.6: undefined symbol: __builtin_dynamic_object_size

Ich habe folgende Toolchain Pakete installiert:

Code: Select all

sys-devel/gcc-11.3.1_p20221209        # nicht neu gebaut
sys-devel/gcc-12.2.1_p20230121-r1     # nicht neu gebaut

sys-devel/binutils-2.38-r2            # nicht neu gebaut
sys-devel/binutils-2.39-r4            # nicht neu gebaut

sys-libs/glibc-2.36-r7                # nicht neu gebaut - needs update
sys-kernel/linux-headers-6.1          # nicht neu gebaut - needs update

sys-libs/binutils-libs-2.39-r4        # nicht neu gebaut - needs update

dev-libs/mpfr-4.2.0_p9                #  <-- neue version gebaut (4.2.0 -> 4.2.0_p9)

Ein Rebuild von mpfr (egal welche in Portage verfügbare Version) bricht ebenfalls mit folgendem Fehler ab:

Code: Select all

configure: error: C compiler cannot create executables
...
/usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1: symbol lookup error: /usr/lib64/libmpfr.so.6: undefined symbol: __builtin_dynamic_object_size

Es ist völlig egal, ob ich GCC 11 oder 12 nutze und es ist auch egal, welche der installierten binutils Versionen ich nutze. Ich habe alle Kombinationen ausprobiert und natürlich source /etc/profile ausgeführt.

Hier noch die Use-Flags von GCC:

Code: Select all

[U] sys-devel/gcc
     Installed versions:  
     11.3.1_p20221209(11)^t(00:26:18 01.01.2023)(cxx fortran hardened nls nptl openmp pie sanitize ssp -ada -cet -custom-cflags -d -debug -doc -fixed-point -go -graphite -jit -libssp -lto -multilib -objc -objc++ -objc-gc -pch -pgo -systemtap -test -valgrind -vanilla -vtv -zstd) 
     12.2.1_p20230121-r1(12)^t(03:02:14 29.01.2023)(cet cxx default-stack-clash-protection default-znow fortran hardened nls nptl openmp pie sanitize ssp -ada -custom-cflags -d -debug -doc -fixed-point -go -graphite -ieee-long-double -jit -libssp -lto -multilib -objc -objc++ -objc-gc -pch -pgo -systemtap -test -valgrind -vanilla -vtv -zstd)

@preserved-rebuild oder revdep-rebuild liefert keine Pakete zum Neubauen.

Bis auf wenige Ausnahmen bin ich auf Stable, Profile default/linux/amd64/17.1/no-multilib/hardened

Habt ihr eine Idee, wie ich das Problem lösen kann?

[Jean-Paul]

Nach dem Update von dev-libs/mpfr solltst du dev-libs/mpc neu bauen
und dann direkt den gcc

https://wiki.gentoo.org/wiki/Mpfr4-update-guide

[forrestfunk81]

Danke für die schnelle Antwort. Ganz vergessen zu erwähnen, dass ich das bereits ausprobiert hatte. Hier kommt der selbe Fehler:

Code: Select all

emerge -1va dev-libs/mpc
...
checking whether the C compiler works... no
configure: error: in `/var/tmp/portage/dev-libs/mpc-1.3.1/work/mpc-1.3.1-abi_x86_64.amd64':
configure: error: C compiler cannot create executables
...

Code: Select all

cat /var/tmp/portage/dev-libs/mpc-1.3.1/work/mpc-1.3.1-abi_x86_64.amd64/config.log
..
configure:3779: checking whether the C compiler works
configure:3801: x86_64-pc-linux-gnu-gcc -march=btver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mxsaveopt -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 -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=btver2 -O2 -pipe  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
/usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1: symbol lookup error: /usr/lib64/libmpfr.so.6: undefined symbol: __builtin_dynamic_object_size
distcc[331] ERROR: compile conftest.c on localhost failed
...

[forrestfunk81]

Hier noch die ldd Outputs:

Code: Select all

# ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1
        linux-vdso.so.1 (0x00007ffe46be4000)
        libmpc.so.3 => /usr/lib64/libmpc.so.3 (0x00007f8ec44af000)
        libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00007f8ec43f7000)
        libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8ec4354000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f8ec433a000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f8ec4260000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8ec408d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8ec44dd000)

# for i in /usr/libexec/gcc/*-pc-linux-gnu/*/cc1; do echo $i; ldd $i | grep mpfr ; done;
/usr/libexec/gcc/x86_64-pc-linux-gnu/11/cc1
        libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00007f4333143000)
/usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1
        libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00007f24a19ce000)

# Update
Ich habe auf der betroffenen Maschine ein DistCC Setup. Aber die Compiles schlagen auf Localhost fehl, die DistCC Remote Hosts sind abgeschalten. Trotzdem war doch da irgendwas mit einem Wrapper, wenn ich mich richtig erinnere.

Code: Select all

# whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/libexec/gcc

# ll /usr/bin/gcc
lrwxrwxrwx 1 root root 39 Jul 25 12:20 /usr/bin/gcc -> /usr/x86_64-pc-linux-gnu/gcc-bin/12/gcc

# ldd /usr/x86_64-pc-linux-gnu/gcc-bin/12/gcc
        linux-vdso.so.1 (0x00007ffc1394a000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5d93672000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5d9349f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5d93757000)

Sollte diese GCC Binary nicht auch gegen libmpfr gelinkt sein, so wie die oben?

[Jean-Paul]

Sollte diese GCC Binary nicht auch gegen libmpfr gelinkt sein, so wie die oben?

Ich denke nicht, sieht bei mir jedenfalls genauso aus wie bei dir.

ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1

linux-vdso.so.1 (0x00007ffe5b36a000)
libmpc.so.3 => /usr/lib64/libmpc.so.3 (0x00007f8872c24000)
libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00007f8872b6c000)
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8872acf000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007f8872ab5000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007f88729dc000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f887280a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8872c63000)

ldd /usr/x86_64-pc-linux-gnu/gcc-bin/12/gcc

linux-vdso.so.1 (0x00007fff0e182000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007f442924d000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f442907b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4429343000)

Aber das deutet darauf hin, dass mit deinen CFLAGS etwas nicht (mehr) stimmt

error: C compiler cannot create executables

Vielleicht mal ein

env-update && source /etc/profile

ausführen

[forrestfunk81]

Aber das deutet darauf hin, dass mit deinen CFLAGS etwas nicht (mehr) stimmt

Daran habe ich nichts geändert. Ich hab sie mal mit dem GCC Output von

Code: Select all

gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 | grep mtune

verglichen und das sieht korrekt aus. Ein Test mit -march=native in der make.conf lieferte die gleiche Fehlermeldung wie zuvor.

Code: Select all

configure:3801: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
/usr/libexec/gcc/x86_64-pc-linux-gnu/12/cc1: symbol lookup error: /usr/lib64/libmpfr.so.6: undefined symbol: __builtin_dynamic_object_size

Vielleicht mal ein

env-update && source /etc/profile

ausführen

Auch getestet, gleiches Ergebnis

[ChrisJumper]

Hast du "native" bei Arch gesetzt oder nicht? Es ist bei Distcc natürlich nicht willkommen wenn mehrere Maschinen zusammen für ein Target rechnen sollen und einer der Dist-CC Server hat eine andere Architektur.

Auch sollten die CFLAGSS gleich sein.. schalte Distcc mal ab.

Du hast in deinem Beispiel zwei verschieden -O Parameter, einmal -O2 und einmal -O1.

Du musst unbedingt mpfr neu bauen, denke ich damit die Adreesierung erneut klappt.

Alternativ kannst du ein Backup machen, in die Machine/festplatte, nach dem Booten einer Livedisk chrooten und die Kern-Programme durch eine Gentoo-Neuinstallation überschreiben.

[forrestfunk81]

Hast du "native" bei Arch gesetzt oder nicht? Es ist bei Distcc natürlich nicht willkommen wenn mehrere Maschinen zusammen für ein Target rechnen sollen und einer der Dist-CC Server hat eine andere Architektur.

Ich habe native wegen DistCC nicht gesetzt, sondern stattdessen die CFlags ermittelt und einzeln gesetzt. Ich habe temporär für einige der oben genannten Versuche march=native gesetzt, nach dem Jean-Paul meinte, dass etwas mit meinen CFlags nicht stimmt.

Auch sollten die CFLAGSS gleich sein.. schalte Distcc mal ab.

DistCC war nach dem der Fehler zum ersten Mal auftrat immer abgeschaltet bzw die anderen Hosts ausgeschaltet. Auf allen beteiligten DistCC Hosts ist cross-compiling mit passender Toolchain eingerichtet.

Du hast in deinem Beispiel zwei verschieden -O Parameter, einmal -O2 und einmal -O1.

Tatsächlich! Das scheint Configure an der Stelle automatisch anzufügen. Bei letzterem Test stand in meiner make.conf nur

Code: Select all

-march=native -O2 -pipe

Du musst unbedingt mpfr neu bauen, denke ich damit die Adreesierung erneut klappt.

Alternativ kannst du ein Backup machen, in die Machine/festplatte, nach dem Booten einer Livedisk chrooten und die Kern-Programme durch eine Gentoo-Neuinstallation überschreiben.

Ja das mit mpfr neu bauen denke ich auch. Ich habe auch schon über eine Neu-/ Parallel-Installation nachgedacht, letzteres wäre eh nicht schlecht als Backup.

Es müsste aber doch auch klappen, wenn ich auf einer anderen Maschine ein Binary Package von mpfr baue, mit den spezifischen CFlags des Betroffenen Rechners, oder? Ich denke das probier ich die nächsten Tage noch aus.

[Christian99]

Ich glaube nicht, dass es was mit den CFLAGS zu tun hat, die sollten mMn keinen Einfluß auf Symbole in einer binary haben. Wie du in diese Situation gekommen bist, versteh ich nicht so ganz, aber nun sind wir nun mal da.
Ich würde versuchen, von einen anderen System, dass nicht mit Prozessorspezifischen Flags gebaut ist, ein mpfr binary package zu machen und auf deinen jetzigen System installieren. Ich glaube das könnte helfen.
Anbieten würde sich auch ein stage3 archiv zu nehmen, da da die sachen nicht mit prozessorspezifischen flags gebaut sind, und man kann es auch aus einer chroot/systemd-nspawn umgebung raus machen.
Im System, aus dem du mpfr rausholen möchtest:

Code: Select all

quickpkg dev-libs/mpfr

dann liegt in $PKGDIR/dev-libs/mpfr eine mpfr-<version>.xpak datei, die du dann in dein jetziges System nach $PKGDIR/dev-libs/mpfr kopierst. ($PKGDIR ist per default /var/cache/binpkgs)

dann machst du

Code: Select all

emerge --oneshot --usepkgonly y dev-libs/mpfr

das sollte dann das binary mpfr package installieren, und gcc/cc1 sollte wieder gehen.

EDIT: zu binary packages siehe hier: https://wiki.gentoo.org/wiki/Binary_package_guide

[forrestfunk81]

Das hat übrigens funktioniert. Binary Package auf einem anderen Host bauen

Code: Select all

export CFLAGS=$flags_der_betroffenen_maschine 
export CXXFLAGS="{$CFLAGS}" 
emerge -Bv mpfr

Das Binary Package dann auf den betroffenen Host kopieren und dort installieren.

Danke