looks, like there is no problem, when running the i686 chroot inside an x86_64 vm - so our build slaves should be safe.

Still, this poses a problem for me :)

looks, like the crux is in glibc:

# strace gcc --version
execve("/usr/bin/gcc", ["gcc", "--version"], 0xbfe4da84 /* 19 vars */) = 0
brk(NULL)                               = 0x9ea7000
arch_prctl(0x3001 /* ARCH_??? */, 0xbfcd48d8) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=21792, ...}) = 0
mmap2(NULL, 21792, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee2000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\301\0\0004\0\0\0"..., 512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=1058520, ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ee0000
mmap2(NULL, 1060880, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ddc000
mmap2(0xb7de8000, 790528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0xb7de8000
mmap2(0xb7ea9000, 217088, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xcd000) = 0xb7ea9000
mmap2(0xb7ede000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x101000) = 0xb7ede000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\353\1\0004\0\0\0"..., 512) = 512
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0004\2132#\246'f-\347\251U\315!\265\323\370"..., 120, 468) = 120
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=2064044, ...}) = 0
mmap2(NULL, 1834708, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c1c000
mmap2(0xb7c39000, 1228800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0xb7c39000
mmap2(0xb7d65000, 442368, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0xb7d65000
mmap2(0xb7dd1000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0xb7dd1000
mmap2(0xb7dd5000, 28372, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7dd5000
close(3)                                = 0
set_thread_area({entry_number=-1, base_addr=0xb7ee1540, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6)
writev(2, [{iov_base="gcc", iov_len=3}, {iov_base=": CPU ISA level is lower than re"..., iov_len=39}], 2gcc: CPU ISA level is lower than required
) = 42
exit_group(127)                         = ?
+++ exited with 127 +++

interestingly, there is no problem on a similar setup for i486 (versions of gcc and glibc are similar, glibc is 2.33-4.1 instead of 2.33-4.0 - also miraculous, considering, that there is no glibc on the buildlist, currently O.o)

I have on testing:
- i486 glibc 2.33-4.2 (12.4. 20:38)
- i686 glibc 2.33-4.2 (12.4. 22:26)
- pentium4 glibc 2.33-4.2 (12.4. 22:08)

I get on i686 only, i486/pentium4 are ok:
gcc: CPU ISA level is lower than required

So, there has been a rebuild of glibc.

893b1c268abc8822332655865e3d4546025a9b4b (13.2.) is the last commit uptream, so this
didn't trigger a rebuild.
620aea01f148b5141342e77b7ee2a6c4e02fedea (9.2.) last commit in our git, so if nobody
triggered a manual rebuild, I also don't understand why we got a new version.

What I also don't get is that rebuilds suddenly result in a misconfiguration again.
Build for i686 all happen chrooted on 64-bit machines.

I'll build a glibc for i686 manually to see if the problem disappears. Just triggering
a glibc rebuild seems a little bit risky now..

Mmh. Interestingly only gcc shows this problem, not for instance 'file' which has also
been rebuilt.

I did trigger the rebuild of glibc - the differing sub_pkgrel's disturbed my common sense for order.

But the phenomenon you describe is exactly, what I had observed: i486 and pentium4 are ok, i686 is broken. Maybe we need to build i686 glibc on an i686 vm?

What do you mean by "rebuilds suddenly result in a misconfiguration again"?

I meant, that libc_cv_include_x86_isa_level=no has no effect on glibc (and thus creating
the ISA level detection error). But it could also be in gcc itself.

IIRC the ISA level problem was present in i686 and pentium4 last time (when I upgraded
glibc to 2.33), but also not on i486.

I triggered a forced rebuild of gcc, this solves the problem in my experiments.