[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?

[Andreas K. Huettel]

Post by Alexander Puchmayr
I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a
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 ...

[Alexander Puchmayr]

Post by Andreas K. Huettel

Post by Alexander Puchmayr
I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a
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

[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

Post by Alexander Puchmayr

Post by Andreas K. Huettel

Post by Alexander Puchmayr
I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a
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 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 should be solved.
Thanks for the hint
Alex

[Nuno Silva]

Post by Alexander Puchmayr

Post by Alexander Puchmayr

Post by Andreas K. Huettel

Post by Alexander Puchmayr
I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and
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 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 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