The error message "CPU ISA level is lower than required" comes from the dynamic loader /lib64/ld-linux-x86-64.so.2, at least on a 64-bit system. I don't know if there is a similar convention in 32-bit linux. There is info about ISA level in the elf header of the binary itself, in note .note.gnu.property, for example
So, the dynamic loader checks all the shared objects needed (see ldd output) what is the highest ISA level needed, whether the CPU ISA level is high enough. No blindly executing and getting a segmentation fault any longer. There could be 'x86 ISA used: x86-64-v2' or x86-64-v3 or x86-64-v4 instead of x86-64-baseline.

EDIT: I guess this wouldn't prevent firefox crashing, as firefox-bin does not have .note.gnu.property. I guess the gnu toolchain would be needed instead of llvm/clang/lld.

1 members found this post helpful.

From the ChangeLog of Slackware 15.0:

Many years ago I messed up my system by upgrading glibc, things might have gotten better since then with version information in the libraries, but to me it still seems to be a need to recompile applications and other libraries.

regards Henrik

Without more context on what it was bumped from, this could be considered "freshening-up", which can be a good thing during distro maintenance (there was alot of that in the 15.0 dev). Recompiles do happen, but you don't necessarily have to rebuild everything. I have continued to run packages from Slackware 14.2 that I have built myself. Honestly if it aint broke, don't mess with it is a really good philosophy. Pat has been pretty good at handling rebuilds -- in the past it was slower paced on the amount of recompiling done. But alot of good work has went into the scripts, so I think it has picked up including more packages in the different phases as the package count increased.

If you have done LFS, you'll know a bit on how things work. But for glibc, I would never replace it on a stable release. Following -current can be a cause for concern if you have to track your changes on top of this. But what is even more an issue would be when you start pulling third party packages that have bleeding edge requirements. If certain distros are bumping the architecture flags more frequently, then more of these questions are going to keep coming in. It'd be nice to know the details on what was being done here.

1 members found this post helpful.

https://www.gnu.org/software/libc/
It is designed to be backwards compatible, however I'm not really sure it is still [really] compatible with the [really] old releases. And if I remember correctly, it [=compatibility] broke down once somewhere before 2.30. But anyway it is strictly tied to the kernel too (and these are [loosely] coupled by the compiler itself).

1 members found this post helpful.

Nope. BBBS software on a VM running new tech. BBBS needs glibc 2.37.

1 members found this post helpful.

For lovers of slackware 14.2
https://sourceware.org/git/?p=glibc....se/2.23/master

For lovers of slackware 15.0
https://sourceware.org/git/?p=glibc....se/2.33/master

This would have been good info in the beginning that you are running on a VM. Your VM is misconfigured. Select a CPU model which supports x86-64-v2, or whatever is needed, instead of plain x86-64-v1.

1 members found this post helpful.

Is it available somewhere? I found this: https://www.bbbs.net/simka/bbbs-2021...nux-64.tar.bz2. It needs only glibc 2.14.

2 members found this post helpful.

It would be surprising if a software released in 2021
needed a library released in 2023.

3 members found this post helpful.

It would be surprising if a software that has a current release on OS/2 requires anything from glibc or x86-64-v2.
I think OP should go to the provider of the bbbs software and ask them to compile the software to a baseline 64-bit cpu on a baseline distro instead of using a bleeding edge distro if they want to advertise it as "64-bit linux". As far as we know this is a very specific binary for a single distro that is only going to work in a specific scenario.

1 members found this post helpful.