Created attachment 699366 [details] /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/xtensa-esp32s2-elf/libgcc/config.log Relevant excerpt from /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/xtensa-esp32s2-elf/libgcc/config.log :- configure:3778: checking for suffix of object files configure:3800: /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/./gcc/ -B/usr/xtensa-esp32s2-elf/bin/ -B/usr/xtensa-esp32s2-elf/lib/ -isystem /usr/xtensa-esp32s 2-elf/include -isystem /usr/xtensa-esp32s2-elf/sys-include -c -g -O2 conftest.c >&5 /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/./gcc/as: line 106: exec: -o: invalid option exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...] configure:3804: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3818: error: in `/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-10.3.0/work/build/xtensa-esp32s2-elf/libgcc': configure:3820: error: cannot compute suffix of object files: cannot compile See `config.log' for more details cross-xtensa-esp32-elf/gcc-10.3.0 works fine. cross-xtensa-esp32s2-elf/gcc-10.2.0-r5 also fails in the same way, although it succeeded back in January - I'm not sure what's changed.
Created attachment 699369 [details] emerge --info
Is your xtensa-esp32s2-elf-as binary working? Can you post the following: 1. `xtensa-esp32s2-elf-as --version` 2. `binutils-config -l`
Hmm how odd, binutils-config said that xtensa-esp32s2-elf had no version selected at all, how did that happen? I'll try merging cross-xtensa-esp32s2-elf/gcc again with that fixed
That seems to have it fixed - so now I'm just left wondering why it takes a few minutes before failing, and why is the error so obscure compared to the actual root cause?
I suspec binutils-config (or binutils) has (or had) a bug in handling upgrade. People very rately report similar issues but it's still not clear what sequence of events is needed to lose the registration.
I guess we can mark this a duplicate of that bug then - I'll report back if it happens again