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

Reply via email to