On Mon, Feb 08, 2021 at 10:25:27AM +0800, Xi Ruoyao wrote: > On 2021-02-07 18:43 +0000, Ken Moffat wrote: > > 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. > > Hi Ken, > > Binutils (assembler "as" and linker "ld") doesn't set ISA "needed" markers by > default. It can be set using special linker option "-z x86-64-v[234]", or > assembly pesudo instructions. > > In glibc building process, crt1.o sets its ISA markers by inline assembly. > Then > its ISA marker just "propagates" to all over the system since most programs > link > to it. > > So the problem is on Glibc side, not Binutils side.
Hi Xi, thanks for that - fun, fun, fun. So the glibc devs are, or were, saying that the binutils devs were doing it wrong. I'll shortly be starting a -march=native build on my skylake box, to see if that replicates the problem (that is currently my oldest usable machine). But I'm quite prepared for a throwaway build if it doesn't run. ;-) ĸ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
