On Sat, Feb 06, 2021 at 10:46:18PM +0800, Xi Ruoyao wrote: > On 2021-02-06 14:56 +0100, Frans de Boer wrote:
> > No, the tests do not stop because I use the 'make -k' option. But can't > > run anything afterwards because of this error. > > BTW, I just tried the --with-cpu=amdfam10 to configure. It halts stating > > that this "subspecies" is not supported. > > > > So, it seems that the glibc dev where playing god and decided that > > anything less then the newest processors should have no means to exist > > anymore. So, I stick for now with the glib-2.32 version and continue later. > > Maybe someone will figure out how to get rid of this absurd ISA level > > check, blocking millions to billions of systems from future updates!! > > Don't assume the upstream is trying to "fight against you". > > It's now reported and the upstream is trying to find a solution: > https://sourceware.org/bugzilla/show_bug.cgi?id=27318 > > For now the best workaround seems "don't use -march". It's a shame that the thread on bug 27318 seems to have ground to a halt last Wednesday, at https://sourceware.org/pipermail/libc-alpha/2021-February/122280.html Quoting from Florian Weimer at the end of the thread. | It's not correct due to the way the check is implemented: failing to | load -march=sandybridge binaries on Sandybridge CPUs is clearly wrong. [...] | If you want checks, doing them against an incorrect ABI level that can | never fully match the host CPU is wrong. He then goes on to sketch an alternative approach, which sounds as if it will need a significant rewrite of what was posted. Earlier in the thread, https://sourceware.org/pipermail/libc-alpha/2021-February/122290.html Joeseph Myers wrote (replying to HJL) | That's bad. Since glibc supports execution on Sandy Bridge processors, | compilation with -march=sandybridge should (a) work, with no special | configure options needed and (b) produce a glibc that works on Sandy | Bridge, with no special configure options needed. I understand that bug | 27318 is reporting that (b) fails at present. We need to fix (b) without | breaking (a). | | This is not specific at all to x86_64. It applies to all architectures | and processors supported by glibc: compiling with a compiler that defaults | to any such processor should just work, regardless of how that processor | relates to particular ISA levels in the glibc-hwcaps machinery. | | > We can add a configure option, --disable-isa-level, to unset | > INCLUDE_X86_ISA_LEVEL. The resulting libc.so doesn't have a marker | > and won't run on all machines. | | No special configure option should be needed for (a) and (b) to hold. | They are general principles for any processor supported by glibc, for any | architecture. To me, this sounds as if the current binutils releases are a severe regression in that what was supposed to help better optimization prevents use of the minimal "build for this specific variant" option. On LFS we do not need the new hwcapabilities (which appears to be a framework for letting distros ship alternate binary versions of some of the libs optimized for different hardware versions). I'm not entirely convinced that I'm going to use current binutils on my own machines if it can't use sensible -march= on the older ones. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
