sliwowitz
Apprentice
Joined: 21 Jan 2005
Posts: 216
Location: Europe/Prague
|
 Posted: Fri Nov 22, 2024 9:03 pm Post subject: CPU ISA level is lower than required (32bit cross-compiled) |
 |
|
I have a x86-64 machine that builds binpkgs for a 32bit Pentium 4 machine. The build machine tyr-cross-master is a 64bit gentoo installation in a VM. When doing updates, I:
- Log in, update the packages in the VM
- Do a bunch of bind mounts and switch to a 32bit chroot with linux32 chroot /usr/i686-pc-linux-gnu /bin/bash --login
- Run emerge world -DNu in the chroot. This builds binpkgs and stores them on a NFS mount.
- Fire up tyr-staging VM which runs a 32bit system
- Update the staging system from the binpkgs on the NFS mount
- Check that everything works
- Log in to the physical 32bit Pentium 4 machine tyr
- Update the physical machine via the same binpkgs
So far this worked fine, but today, glibc-2.40-r5 was built which doesn't work on the 32bit hardware
In the 32bit build chroot, I have:
| Code: | (chroot)tyr-cross-master / # emerge --info
Portage 3.0.66.1 (python 3.13.0-final-0, default/linux/x86/23.0/i686, gcc-14, glibc-2.40-r5, 6.6.62-gentoo-kvm i686)
=================================================================
System uname: Linux-6.6.62-gentoo-kvm-i686-Intel_Xeon_Processor_-Skylake,_IBRS-with-glibc2.40
...
CBUILD="i686-pc-linux-gnu"
CFLAGS="-m32 -march=pentium4 -O3 -pipe -fomit-frame-pointer -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=auto -fuse-linker-plugin"
CHOST="i686-pc-linux-gnu"
|
On this 64bit VM in 32bit chroot, the new glibc-2.40-r5 works.
In the staging VM:
| Code: |
tyr-staging ~ # emerge --info
Portage 3.0.66.1 (python 3.13.0-final-0, default/linux/x86/23.0/i686, gcc-13, glibc-2.40-r5, 6.6.62-gentoo-tyr-staging i686)
=================================================================
System uname: Linux-6.6.62-gentoo-tyr-staging-i686-Intel_Xeon_Processor_-Skylake,_IBRS-with-glibc2.40
...
CBUILD="i686-pc-linux-gnu"
CFLAGS="-m32 -O3 -march=pentium4 -pipe -fomit-frame-pointer -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin"
CHOST="i686-pc-linux-gnu"
|
On this 32bit VM it still works (maybe because the physical CPU actually supports that ISA)
The real Pentium 4 hardware, after glibc-2.40-r5 was installed:
| Code: |
tyr /home/mame # emerge --info
Portage 3.0.65 (python 3.12.6-final-0, default/linux/x86/23.0/i686, gcc-13, glibc-2.40-r5, 6.6.52-gentoo-mame i686)
=================================================================
System uname: Linux-6.6.52-gentoo-mame-i686-with-glibc2.40
...
CBUILD="i686-pc-linux-gnu"
CFLAGS="-m32 -O3 -march=pentium4 -pipe -fomit-frame-pointer -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=1 -fuse-linker-plugin"
CHOST="i686-pc-linux-gnu"
|
Here it fails spectaculary. After emerge updates glibc, almost everything starts throwing CPU ISA level is lower than required error. I'm stuck in a terminal where I can't do e.g. ls (though I could run emerge --info, so maybe python is yet unaffected, but I can't emerge packages due to failing basic commands like find).
Looking at libc.so.6:
| Code: |
(chroot)tyr-cross-master / # readelf -n /lib/libc.so.6
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000024 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA needed: x86-64-baseline
x86 feature used: x86, x87, XMM
x86 ISA used: x86-64-baseline
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.2.0
|
The surpising part to me is x86 ISA needed: x86-64-baseline as this is supposed to be a purely 32bit build, though perhaps even more surprisingly, the older glibc-2.39-r9 shows the exact same readelf output, yet it has worked fine on the physical machine since August.
What's wrong with my glibc-2.40-r5 build? How do I build it properly so that it would work on the 32bit hardware as did the earlier versions?
_________________
The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
-- Edsger Dijkstra |
|
Portage & Programming
