[gentoo-user] CPU ISA level is lower than required

[gentoo-user] CPU ISA level is lower than required

[Alexander Puchmayr]

Hi,

I tried to tweak some settings regarding CFLAGS="march=x86-64-v2" on my 
buildhost and then install the binary packages on the target machines.

Buildhost: AMD Ryzen 7 2700; ld.so --help says:
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Target platform: AMD A8-5500; ld.so --help says
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a 
emerge -ev @world, re-creating all packages in binary form.

My expectation was that these packages would work on the target platform, but 
they don't. Error message "CPU ISA level is lower than required". 

Q: The binary (e.g. /usr/bin/bzip2) obviously "knows" what it requires. How do 
I find out what this is? Neither ldd, ld.so or the like seem to give me this 
information.

Q: Does the xpak format encode those requirements in any way, if so , how can 
I read them?

Q: Can I compile binary packages with multiple ISA sets and let portage on the 
target machine decide which sub-package to use depending on capabilities of 
the target CPU?

Re: [gentoo-user] CPU ISA level is lower than required

[Andreas K. Huettel]

> 
> I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a 
> emerge -ev @world, re-creating all packages in binary form.
> 
> My expectation was that these packages would work on the target platform, but 
> they don't. Error message "CPU ISA level is lower than required". 
> 

Quiz question: did you rebuild your toolchain *before* or *after* bzip2?

Suspicion without proof, the startup code embedded by gcc and glibc may well be
affected by the microarchitecture level. As may be libraries statically linked
in...

The safer way would be to run emerge -ev world, and afterwards build the
packages with a second emerge -ev world ...

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

Re: [gentoo-user] CPU ISA level is lower than required

[Alexander Puchmayr]

Am Sonntag, 3. März 2024, 14:32:41 CET schrieb Andreas K. Huettel:
> > I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a
> > emerge -ev @world, re-creating all packages in binary form.
> > 
> > My expectation was that these packages would work on the target platform,
> > but they don't. Error message "CPU ISA level is lower than required".
> 
> Quiz question: did you rebuild your toolchain *before* or *after* bzip2?
> 
> Suspicion without proof, the startup code embedded by gcc and glibc may well
> be affected by the microarchitecture level. As may be libraries statically
> linked in...
> 
> The safer way would be to run emerge -ev world, and afterwards build the
> packages with a second emerge -ev world ...

Indeed, that seems to be the problem. I remember, my first try was with -v3 (as 
my buildhost supported this), and, after discovering the "surprise" on the 
target machine, started the emerge -ev @world. Likely, glibc was not the first 
package, so there are an unknown number of packets that have the problem.

I started to recompile the "usual suspects", like bzip2 and xz, which made it 
a bit better, but still the emerge -uavDNk @world did not succeed.

Now I'm doing again a emerge -ev @world on my buildhost again, so tomorrow it 
should be solved.

Thanks for the hint
	Alex

Re: [gentoo-user] CPU ISA level is lower than required

[Alexander Puchmayr]

Hi there,

Unfortunately this still did not help.

I repeat my original question:

Q: The binary (e.g. /usr/bin/bzip2) obviously "knows" what it requires. How do 
I find out what this is? Neither ldd, ld.so or the like seem to give me this 
information.

BR
   Alex


On Sonntag, 3. März 2024, 18:45:16 CET Alexander Puchmayr wrote:
> Am Sonntag, 3. März 2024, 14:32:41 CET schrieb Andreas K. Huettel:
> > > I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed
> > > a
> > > emerge -ev @world, re-creating all packages in binary form.
> > > 
> > > My expectation was that these packages would work on the target
> > > platform,
> > > but they don't. Error message "CPU ISA level is lower than required".
> > 
> > Quiz question: did you rebuild your toolchain *before* or *after* bzip2?
> > 
> > Suspicion without proof, the startup code embedded by gcc and glibc may
> > well be affected by the microarchitecture level. As may be libraries
> > statically linked in...
> > 
> > The safer way would be to run emerge -ev world, and afterwards build the
> > packages with a second emerge -ev world ...
> 
> Indeed, that seems to be the problem. I remember, my first try was with -v3
> (as my buildhost supported this), and, after discovering the "surprise" on
> the target machine, started the emerge -ev @world. Likely, glibc was not
> the first package, so there are an unknown number of packets that have the
> problem.
> 
> I started to recompile the "usual suspects", like bzip2 and xz, which made
> it a bit better, but still the emerge -uavDNk @world did not succeed.
> 
> Now I'm doing again a emerge -ev @world on my buildhost again, so tomorrow
> it should be solved.
> 
> Thanks for the hint
> 	Alex

[gentoo-user] Re: CPU ISA level is lower than required

[Nuno Silva]

On 2024-03-04, Alexander Puchmayr wrote:
> On Sonntag, 3. März 2024, 18:45:16 CET Alexander Puchmayr wrote:
>> Am Sonntag, 3. März 2024, 14:32:41 CET schrieb Andreas K. Huettel:
>> > > I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and
>> > > performed a emerge -ev @world, re-creating all packages in binary
>> > > form.
>> > > 
>> > > My expectation was that these packages would work on the target
>> > > platform, but they don't. Error message "CPU ISA level is lower
>> > > than required".
>> > 
>> > Quiz question: did you rebuild your toolchain *before* or *after* bzip2?
>> > 
>> > Suspicion without proof, the startup code embedded by gcc and glibc may
>> > well be affected by the microarchitecture level. As may be libraries
>> > statically linked in...
>> > 
>> > The safer way would be to run emerge -ev world, and afterwards build the
>> > packages with a second emerge -ev world ...
>> 
>> Indeed, that seems to be the problem. I remember, my first try was with -v3
>> (as my buildhost supported this), and, after discovering the "surprise" on
>> the target machine, started the emerge -ev @world. Likely, glibc was not
>> the first package, so there are an unknown number of packets that have the
>> problem.
>> 
>> I started to recompile the "usual suspects", like bzip2 and xz, which made
>> it a bit better, but still the emerge -uavDNk @world did not succeed.
>> 
>> Now I'm doing again a emerge -ev @world on my buildhost again, so tomorrow
>> it should be solved.
>
> Unfortunately this still did not help.

There is [1] from 2021 also with -march, but it was worked around back
then and that was several years ago. But could it be the same thing?

[1] https://forums.gentoo.org/viewtopic-t-1129458-start-0.html

It'd at least explain why the message is showing up... but while the
in-tree glibc-2.38 ebuilds do not have the line added in [2], the commit
to glibc-9999.ebuild says this is supposed to have been addressed
upstream [3].

[2] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5dbd6a821ff753e3b41324c4fb7c58cf65eeea33
[3] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1f0fd3e2aee01e0c09e7103c8af4183b57faef49

-- 
Nuno Silva