Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, Feb 11, 2021 at 12:01:12PM -0600, Bruce Dubbs wrote: > On 2/11/21 8:38 AM, Ken Moffat wrote: > > On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: > > > > I've now applied that to 5.10.15-rc1 and confirmed it builds and > > boots. Gotta go out right now for provisions, will use my other > > mail to inform the relevant people that this fixes builds with > > binutils-2.36.1 when I get back. > > The 5.10.15 kernel is now out, but I can confirm that the patch above has > NOT been incorporated. > > Do we know when 5.11 will be released? We are scheduled to go into package > freeze on Sunday, but if it is not fixed yet, I think we should wait for it. > > -- Bruce > 5.11 is expected on Sunday night. We normally wait for .1 versions (and the patch has missed 5.10.16 by the look of things (5.10.16-rc1 was released before I sent my mail), no idea if it will arrive in 5.10.18 - it looks as if it had been filed under "breaks clang, but that is maybe broken anyway" (although Linus apparently now uses it). And we are expecting the (low severity) new version of OpenSSL next Tuesday. Broadening this, any thought on the change to adapt glibc for (at least) older AMD K10 hardware ? ĸ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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2/11/21 2:19 PM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 12:01:12PM -0600, Bruce Dubbs wrote: On 2/11/21 8:38 AM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: I've now applied that to 5.10.15-rc1 and confirmed it builds and boots. Gotta go out right now for provisions, will use my other mail to inform the relevant people that this fixes builds with binutils-2.36.1 when I get back. The 5.10.15 kernel is now out, but I can confirm that the patch above has NOT been incorporated. Do we know when 5.11 will be released? We are scheduled to go into package freeze on Sunday, but if it is not fixed yet, I think we should wait for it. -- Bruce 5.11 is expected on Sunday night. We normally wait for .1 versions (and the patch has missed 5.10.16 by the look of things (5.10.16-rc1 was released before I sent my mail), no idea if it will arrive in 5.10.18 - it looks as if it had been filed under "breaks clang, but that is maybe broken anyway" (although Linus apparently now uses it). And we are expecting the (low severity) new version of OpenSSL next Tuesday. Broadening this, any thought on the change to adapt glibc for (at least) older AMD K10 hardware ? On the glibc change, we should definitely proceed I think. I can reproduce it on Sandy Bridge Intel as well, and my SysV box is affected too. This is a tough one, hopefully Bruce has more insight. We could just do -rc1 with Linux 5.11 (no point version), but not sure if that's the best way to approach things either - Doug -- 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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote:
> On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote:
> > On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> > > Bonjour Xi (hello the list),
> > >
> > > On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > > > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > >
> > > > > I managed to compile objtool with -g, to recompile apic.c to
> > > > > apic.o
> > > > > (because it gets erased when objtool fails), and to run the
> > > > > objtool
> > > > > command on it under gdb. The segfault is esay to understand:
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x00412f71 in elf_rebuild_rela_reloc_section
> > > > > (sec=0xe22b10,
> > > > > nr=16)
> > > > > at elf.c:883
> > > > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > > > sym-
> > > > > > idx, reloc->type);
> > > > >
> > > > > and the reloc struct is:
> > > > > (gdb) p *reloc
> > > > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > > > 0x0,
> > > > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0,
> > > > > r_addend
> > > > > =
> > > > > 0},
> > > > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym =
> > > > > 0x0,
> > > > > offset = 48,
> > > > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > > > >
> > > > > So reloc->sym is zero, and reloc->sym->idx is a null
> > > > > dereference...
> > > > >
> > > > > Now to understand why reloc->sym is zero is more complicated...
> > > >
> > > > I can reproduce it too with Ken's config and just "make
> > > > arch/x86/kernel/apic/apic.o".
> > > >
> > > > I seen a strange warning in build:
> > > >
> > > > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c'
> > > > > differs
> > > > > from latest
> > > > > version at 'arch/x86/lib/insn.c'
> > > >
> > > > Not sure if it causes the segfault. I'll try 5.10.15 and if it's
> > > > not
> > > > fixed I'll
> > > > report it as a kernel bug.
> > > do you confirm it is binutil-2.36.1 related or
> > > is it a kernel only problem?
> >
> > I can't confirm or disconfirm. It's beyond my knowledge. But I
> > decided to
> > report it to the kernel bugzilla. If kernel dev thinks it's a
> > binutils bug they
> > can report to binutils anyway.
> >
> > And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev
> > may have
> > some idea of it.
>
> Looks like
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21
>
>
> fixes it (at least with Ken's configuration). I've applied this patch
> to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin
> firmware to /lib/frimware/i915 to allow the build with Ken's config).
>
> Pierre
>
Pierre, thanks for finding the patch. After I'd gone to bed it
occurred to me that I would need to download earlier 5.11-rc kernels
to find which one fixed it, and then do a reverse bisect to find
which commit fixed it (the logic of that always makes me even more
confused than normal), so many thanks for saving me that confusion!
I've now applied that to 5.10.15-rc1 and confirmed it builds and
boots. Gotta go out right now for provisions, will use my other
mail to inform the relevant people that this fixes builds with
binutils-2.36.1 when I get back.
Cheers.
ĸ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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2/11/21 8:38 AM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote: On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote: [snip] And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev may have some idea of it. Looks like https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21 fixes it (at least with Ken's configuration). I've applied this patch to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin firmware to /lib/frimware/i915 to allow the build with Ken's config). Pierre Pierre, thanks for finding the patch. After I'd gone to bed it occurred to me that I would need to download earlier 5.11-rc kernels to find which one fixed it, and then do a reverse bisect to find which commit fixed it (the logic of that always makes me even more confused than normal), so many thanks for saving me that confusion! I've now applied that to 5.10.15-rc1 and confirmed it builds and boots. Gotta go out right now for provisions, will use my other mail to inform the relevant people that this fixes builds with binutils-2.36.1 when I get back. The 5.10.15 kernel is now out, but I can confirm that the patch above has NOT been incorporated. Do we know when 5.11 will be released? We are scheduled to go into package freeze on Sunday, but if it is not fixed yet, I think we should wait for it. -- Bruce -- 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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote:
> On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> > Bonjour Xi (hello the list),
> >
> > On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > > > >
> > > > > > > Looks like I need to change the Frame pointer unwinder to
> > > > > > > the
> > > > > > > ORC unwinder to have the same config as you.
> > > > > > >
> > > > > >
> > > > > > The benefits of the ORC unwinder are mentioned at
> > > > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > > > >
> > > > > > It has been around for quite some time, but I probably
> > > > > > picked
> > > > > > it
> > > > > > up when it first appeared (test an -rc kernel, pick up new
> > > > > > options
> > > > > > which might be useful). I guess that old configs from
> > > > > > before
> > > > > > its
> > > > > > introduction still default to the old unwinder.
> > > > > >
> > > > > In fact it caused trouble about 3 years ago, there are links
> > > > > to
> > > > > the
> > > > > -dev archive from around January 2018 when elfutils was still
> > > > > in
> > > > > BLFS, and at that time LFS had to use the frame pointer. So
> > > > > when
> > > > > libelf arrived in LFS I started to use it (or use it again,
> > > > > not
> > > > > sure
> > > > > which).
> > > > >
> > > >
> > > > I managed to compile objtool with -g, to recompile apic.c to
> > > > apic.o
> > > > (because it gets erased when objtool fails), and to run the
> > > > objtool
> > > > command on it under gdb. The segfault is esay to understand:
> > > >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x00412f71 in elf_rebuild_rela_reloc_section
> > > > (sec=0xe22b10,
> > > > nr=16)
> > > > at elf.c:883
> > > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > > sym-
> > > > > idx, reloc->type);
> > > >
> > > > and the reloc struct is:
> > > > (gdb) p *reloc
> > > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > > 0x0,
> > > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0,
> > > > r_addend
> > > > =
> > > > 0},
> > > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym =
> > > > 0x0,
> > > > offset = 48,
> > > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > > >
> > > > So reloc->sym is zero, and reloc->sym->idx is a null
> > > > dereference...
> > > >
> > > > Now to understand why reloc->sym is zero is more complicated...
> > >
> > > I can reproduce it too with Ken's config and just "make
> > > arch/x86/kernel/apic/apic.o".
> > >
> > > I seen a strange warning in build:
> > >
> > > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c'
> > > > differs
> > > > from latest
> > > > version at 'arch/x86/lib/insn.c'
> > >
> > > Not sure if it causes the segfault. I'll try 5.10.15 and if it's
> > > not
> > > fixed I'll
> > > report it as a kernel bug.
> > do you confirm it is binutil-2.36.1 related or
> > is it a kernel only problem?
>
> I can't confirm or disconfirm. It's beyond my knowledge. But I
> decided to
> report it to the kernel bugzilla. If kernel dev thinks it's a
> binutils bug they
> can report to binutils anyway.
>
> And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev
> may have
> some idea of it.
Looks like
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21
fixes it (at least with Ken's configuration). I've applied this patch
to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin
firmware to /lib/frimware/i915 to allow the build with Ken's config).
Pierre
--
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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> Bonjour Xi (hello the list),
>
> On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > > >
> > > > > > Looks like I need to change the Frame pointer unwinder to the
> > > > > > ORC unwinder to have the same config as you.
> > > > > >
> > > > >
> > > > > The benefits of the ORC unwinder are mentioned at
> > > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > > >
> > > > > It has been around for quite some time, but I probably picked
> > > > > it
> > > > > up when it first appeared (test an -rc kernel, pick up new
> > > > > options
> > > > > which might be useful). I guess that old configs from before
> > > > > its
> > > > > introduction still default to the old unwinder.
> > > > >
> > > > In fact it caused trouble about 3 years ago, there are links to
> > > > the
> > > > -dev archive from around January 2018 when elfutils was still in
> > > > BLFS, and at that time LFS had to use the frame pointer. So when
> > > > libelf arrived in LFS I started to use it (or use it again, not
> > > > sure
> > > > which).
> > > >
> > >
> > > I managed to compile objtool with -g, to recompile apic.c to apic.o
> > > (because it gets erased when objtool fails), and to run the objtool
> > > command on it under gdb. The segfault is esay to understand:
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> > > nr=16)
> > > at elf.c:883
> > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > sym-
> > > > idx, reloc->type);
> > >
> > > and the reloc struct is:
> > > (gdb) p *reloc
> > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > 0x0,
> > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend
> > > =
> > > 0},
> > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> > > offset = 48,
> > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > >
> > > So reloc->sym is zero, and reloc->sym->idx is a null dereference...
> > >
> > > Now to understand why reloc->sym is zero is more complicated...
> >
> > I can reproduce it too with Ken's config and just "make
> > arch/x86/kernel/apic/apic.o".
> >
> > I seen a strange warning in build:
> >
> > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs
> > > from latest
> > > version at 'arch/x86/lib/insn.c'
> >
> > Not sure if it causes the segfault. I'll try 5.10.15 and if it's not
> > fixed I'll
> > report it as a kernel bug.
> do you confirm it is binutil-2.36.1 related or
> is it a kernel only problem?
I can't confirm or disconfirm. It's beyond my knowledge. But I decided to
report it to the kernel bugzilla. If kernel dev thinks it's a binutils bug they
can report to binutils anyway.
And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev may have
some idea of it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Bonjour Xi (hello the list),
On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > >
> > > > > Looks like I need to change the Frame pointer unwinder to the
> > > > > ORC unwinder to have the same config as you.
> > > > >
> > > >
> > > > The benefits of the ORC unwinder are mentioned at
> > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > >
> > > > It has been around for quite some time, but I probably picked
> > > > it
> > > > up when it first appeared (test an -rc kernel, pick up new
> > > > options
> > > > which might be useful). I guess that old configs from before
> > > > its
> > > > introduction still default to the old unwinder.
> > > >
> > > In fact it caused trouble about 3 years ago, there are links to
> > > the
> > > -dev archive from around January 2018 when elfutils was still in
> > > BLFS, and at that time LFS had to use the frame pointer. So when
> > > libelf arrived in LFS I started to use it (or use it again, not
> > > sure
> > > which).
> > >
> >
> > I managed to compile objtool with -g, to recompile apic.c to apic.o
> > (because it gets erased when objtool fails), and to run the objtool
> > command on it under gdb. The segfault is esay to understand:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> > nr=16)
> > at elf.c:883
> > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > >sym-
> > > idx, reloc->type);
> >
> > and the reloc struct is:
> > (gdb) p *reloc
> > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > 0x0,
> > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend
> > =
> > 0},
> > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> > offset = 48,
> > type = 2, addend = 467, idx = 0, jump_table_start = false}
> >
> > So reloc->sym is zero, and reloc->sym->idx is a null dereference...
> >
> > Now to understand why reloc->sym is zero is more complicated...
>
> I can reproduce it too with Ken's config and just "make
> arch/x86/kernel/apic/apic.o".
>
> I seen a strange warning in build:
>
> > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs
> > from latest
> > version at 'arch/x86/lib/insn.c'
>
> Not sure if it causes the segfault. I'll try 5.10.15 and if it's not
> fixed I'll
> report it as a kernel bug.
do you confirm it is binutil-2.36.1 related or
is it a kernel only problem?
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
>
--
You have seen "Linux from scratch" and looking for ISO files
www.osukiss.org
--
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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > >
> > > > Looks like I need to change the Frame pointer unwinder to the
> > > > ORC unwinder to have the same config as you.
> > > >
> > >
> > > The benefits of the ORC unwinder are mentioned at
> > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > >
> > > It has been around for quite some time, but I probably picked it
> > > up when it first appeared (test an -rc kernel, pick up new options
> > > which might be useful). I guess that old configs from before its
> > > introduction still default to the old unwinder.
> > >
> > In fact it caused trouble about 3 years ago, there are links to the
> > -dev archive from around January 2018 when elfutils was still in
> > BLFS, and at that time LFS had to use the frame pointer. So when
> > libelf arrived in LFS I started to use it (or use it again, not sure
> > which).
> >
>
> I managed to compile objtool with -g, to recompile apic.c to apic.o
> (because it gets erased when objtool fails), and to run the objtool
> command on it under gdb. The segfault is esay to understand:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> nr=16)
> at elf.c:883
> 883 relocs[idx].r_info = GELF_R_INFO(reloc->sym-
> > idx, reloc->type);
>
> and the reloc struct is:
> (gdb) p *reloc
> $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next = 0x0,
> pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend =
> 0},
> rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> offset = 48,
> type = 2, addend = 467, idx = 0, jump_table_start = false}
>
> So reloc->sym is zero, and reloc->sym->idx is a null dereference...
>
> Now to understand why reloc->sym is zero is more complicated...
I can reproduce it too with Ken's config and just "make
arch/x86/kernel/apic/apic.o".
I seen a strange warning in build:
> Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs from latest
> version at 'arch/x86/lib/insn.c'
Not sure if it causes the segfault. I'll try 5.10.15 and if it's not fixed I'll
report it as a kernel bug.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote: > > > > Looks like I need to change the Frame pointer unwinder to the > > ORC unwinder to have the same config as you. > > > > The benefits of the ORC unwinder are mentioned at > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html > > It has been around for quite some time, but I probably picked it > up when it first appeared (test an -rc kernel, pick up new options > which might be useful). I guess that old configs from before its > introduction still default to the old unwinder. > In fact it caused trouble about 3 years ago, there are links to the -dev archive from around January 2018 when elfutils was still in BLFS, and at that time LFS had to use the frame pointer. So when libelf arrived in LFS I started to use it (or use it again, not sure which). ĸ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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 09:39:20PM +0100, Pierre Labastie wrote: > On Wed, 2021-02-10 at 16:32 +, Ken Moffat wrote: > > On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > > > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > > > > > Since you two are the only ones (among the persons on this list, up > > > to > > > now) who see this, I guess it has something to do with either: > > > - an option in the config, that you use and the others don't > > > - some CFLAGS settings, but I doubt it, because the kernel build > > > system > > > resets them > > > > > > > > > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error > > > > > > 4 in > > > > > > objtool[402000+11000] > > > > > > followed by a dump of the code bytes. > > > > > > objtool is a kernel thing. According to > > > tools/objtool/Documentation/stack-validation.txt, > > > " > > > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > > > objtool which runs at compile time. It has a "check" subcommand > > > which > > > analyzes every .o file and ensures the validity of its stack > > > metadata. > > > It enforces a set of rules on asm code and C inline assembly code > > > so > > > that stack traces can be reliable. > > > " > > > > > > Note that I do have that option set to y, but maybe other options > > > in > > > the "Compile-time checks and compiler options" may differ... > > > > > > rebuilding with "make V=1", I see that objtool is run after each > > > compilation. It might be interesting to compare the options that > > > are > > > passed to objtool in my case and in yours. Mine has: > > > ./tools/objtool/objtool check --retpoline --uaccess \ > > > arch/x86/kernel/apic/apic.o > > > > > > (same options for any object file, but I show the one that might be > > > faulty in your case). > > > > > > Maybe "gdb objtool" would allow to learn more (but may need to > > > recompile objtool with debug enabled, I'm not sure how to do that) > > > > > > Pierre > > > > > > > Hi all, > > > > I've gone back to my skylake and attempted a fresh build of 5.10.14. > > I used KBUILD_VERBOSE=1, for objtool I have: > > > > ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ > > arch/x86/kernel/apic/apic.o > > > > Note that the segfault seems to be happening *before* what you quote > > above (in generate, check presumably comes after that). > > > > The full command leading up to the error (not reformatted, > > everything between gcc and apic.c is one line): > > > > make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ > > \ > > need-builtin=1 \ > > need-modorder=1 > > gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include -I./arch/x86/include > > -I./arch/x86/include/generated -I./include > > -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi > > -I./include/uapi -I./include/generated/uapi -include > > ./include/linux/kconfig.h -include ./include/linux/compiler_types.h > > -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef > > -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing > > -fno-common -fshort-wchar -fno-PIE > > -Werror=implicit-function-declaration -Werror=implicit-int > > -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse > > -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 > > -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 > > -mpreferred-stack-boundary=3 -mskip-rax-setup -march=core2 > > -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -Wno-sign-compare > > -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern > > -mindirect-branch-register -fno-jump-tables > > -fno-delete-null-pointer-checks -Wno-frame-address > > -Wno-format-truncation -Wno-format-overflow > > -Wno-address-of-packed-member -O2 -fno-allow-store-data-races > > -Wframe-larger-than=2048 -fstack-protector-strong > > -Wno-unused-but-set-variable -Wimplicit-fallthrough > > -Wno-unused-const-variable -pg -mrecord-mcount -mfentry > > -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla > > -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds > > -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict > > -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check > > -fconserve-stack -Werror=date-time > > -Werror=incompatible-pointer-types -Werror=designated-init > > -fcf-protection=none -Wno-packed-not-aligned > > -fplugin=./scripts/gcc-plugins/latent_entropy_plugin.so > > -fplugin=./scripts/gcc-plugins/structleak_plugin.so > > -fplugin=./scripts/gcc-plugins/randomize_layout_plugin.so > > -DLATENT_ENTROPY_PLUGIN -fplugin-arg-structleak_plugin-byref-all > > -DSTRUCTLEAK_PLUGIN -DRANDSTRUCT_PLUGIN > > -fplugin-arg-randomize_layout_plugin-performance-mode > > -DKBUILD_MODFILE='"arch/x86/kernel/apic/apic"' > > -DKBUILD_BASENAME='"apic"' -DKBUILD_MODNAME='"apic"' -c -o > >
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > >
> > > Looks like I need to change the Frame pointer unwinder to the
> > > ORC unwinder to have the same config as you.
> > >
> >
> > The benefits of the ORC unwinder are mentioned at
> > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> >
> > It has been around for quite some time, but I probably picked it
> > up when it first appeared (test an -rc kernel, pick up new options
> > which might be useful). I guess that old configs from before its
> > introduction still default to the old unwinder.
> >
> In fact it caused trouble about 3 years ago, there are links to the
> -dev archive from around January 2018 when elfutils was still in
> BLFS, and at that time LFS had to use the frame pointer. So when
> libelf arrived in LFS I started to use it (or use it again, not sure
> which).
>
I managed to compile objtool with -g, to recompile apic.c to apic.o
(because it gets erased when objtool fails), and to run the objtool
command on it under gdb. The segfault is esay to understand:
Program received signal SIGSEGV, Segmentation fault.
0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
nr=16)
at elf.c:883
883 relocs[idx].r_info = GELF_R_INFO(reloc->sym-
>idx, reloc->type);
and the reloc struct is:
(gdb) p *reloc
$2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next = 0x0,
pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend =
0},
rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
offset = 48,
type = 2, addend = 467, idx = 0, jump_table_start = false}
So reloc->sym is zero, and reloc->sym->idx is a null dereference...
Now to understand why reloc->sym is zero is more complicated...
Pierre
--
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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > Hello, > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > > > ../configure --prefix=/usr \ > > > > > --disable-werror \ > > > > > --enable-kernel=3.2 \ > > > > > --enable-stack-protector=strong \ > > > > > --with-headers=/usr/include \ > > > > > libc_cv_slibdir=/lib > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > > slow > > > > > DRAM) and I'm not sure it will get very far before I go to > > > > > bed. > > > > > My > > > > > revised plan is to wait for it to fail, whether that is failign > > > > > the > > > > > build or failing to boot. > > > > > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > > > > > Well I don't need that workaround for using '-march=native -O2' > > > > on > > > > my skylake, it booted successfully. Fortunately, Frans said it > > > > works for him, and htat distros are using it, so I guess we too > > > > should use it. > > > > > > > > However, there was one problem other than my own typos in editing > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > make[3]: *** [scripts/Makefile.build:279: > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > Exact same problem here (not a memory problem, or very big > > "cosmic ray"). same problem on kernel-5.10.9 too. > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > glibc-2.32 make the segmentation fault (I previously restarted > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > compilation was OK). > > My conclusion, binutils is the trouble maker. > > Could somebody confirm this finding? > > Google is mute on this subject but may be my search > > keywords were not that good. > > advices? suggestions? > > Since you two are the only ones (among the persons on this list, up to > now) who see this, I guess it has something to do with either: > - an option in the config, that you use and the others don't > - some CFLAGS settings, but I doubt it, because the kernel build system > resets them > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > > > objtool[402000+11000] > > > > followed by a dump of the code bytes. > > objtool is a kernel thing. According to > tools/objtool/Documentation/stack-validation.txt, > " > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > objtool which runs at compile time. It has a "check" subcommand which > analyzes every .o file and ensures the validity of its stack metadata. > It enforces a set of rules on asm code and C inline assembly code so > that stack traces can be reliable. > " > > Note that I do have that option set to y, but maybe other options in > the "Compile-time checks and compiler options" may differ... > > rebuilding with "make V=1", I see that objtool is run after each > compilation. It might be interesting to compare the options that are > passed to objtool in my case and in yours. Mine has: > ./tools/objtool/objtool check --retpoline --uaccess \ > arch/x86/kernel/apic/apic.o > > (same options for any object file, but I show the one that might be > faulty in your case). > > Maybe "gdb objtool" would allow to learn more (but may need to > recompile objtool with debug enabled, I'm not sure how to do that) > > Pierre > Hi all, I've gone back to my skylake and attempted a fresh build of 5.10.14. I used KBUILD_VERBOSE=1, for objtool I have: ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ arch/x86/kernel/apic/apic.o Note that the segfault seems to be happening *before* what you quote above (in generate, check presumably comes after that). The full command leading up to the error (not reformatted, everything between gcc and apic.c is one line): make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ \ need-builtin=1 \ need-modorder=1 gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, 2021-02-10 at 16:32 +, Ken Moffat wrote: > On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > > Hello, > > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > > > > > ../configure --prefix=/usr \ > > > > > > --disable-werror \ > > > > > > --enable-kernel=3.2 \ > > > > > > --enable-stack-protector=strong \ > > > > > > --with-headers=/usr/include \ > > > > > > libc_cv_slibdir=/lib > > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > > > slow > > > > > > DRAM) and I'm not sure it will get very far before I go to > > > > > > bed. > > > > > > My > > > > > > revised plan is to wait for it to fail, whether that is > > > > > > failign > > > > > > the > > > > > > build or failing to boot. > > > > > > > > > > > > Assuming it does fail, I'll start again with that > > > > > > workaround. > > > > > > > > > > > Well I don't need that workaround for using '-march=native - > > > > > O2' > > > > > on > > > > > my skylake, it booted successfully. Fortunately, Frans said > > > > > it > > > > > works for him, and htat distros are using it, so I guess we > > > > > too > > > > > should use it. > > > > > > > > > > However, there was one problem other than my own typos in > > > > > editing > > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > > make[3]: *** [scripts/Makefile.build:279: > > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > > Exact same problem here (not a memory problem, or very big > > > "cosmic ray"). same problem on kernel-5.10.9 too. > > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > > glibc-2.32 make the segmentation fault (I previously restarted > > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > > compilation was OK). > > > My conclusion, binutils is the trouble maker. > > > Could somebody confirm this finding? > > > Google is mute on this subject but may be my search > > > keywords were not that good. > > > advices? suggestions? > > > > Since you two are the only ones (among the persons on this list, up > > to > > now) who see this, I guess it has something to do with either: > > - an option in the config, that you use and the others don't > > - some CFLAGS settings, but I doubt it, because the kernel build > > system > > resets them > > > > > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error > > > > > 4 in > > > > > objtool[402000+11000] > > > > > followed by a dump of the code bytes. > > > > objtool is a kernel thing. According to > > tools/objtool/Documentation/stack-validation.txt, > > " > > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > > objtool which runs at compile time. It has a "check" subcommand > > which > > analyzes every .o file and ensures the validity of its stack > > metadata. > > It enforces a set of rules on asm code and C inline assembly code > > so > > that stack traces can be reliable. > > " > > > > Note that I do have that option set to y, but maybe other options > > in > > the "Compile-time checks and compiler options" may differ... > > > > rebuilding with "make V=1", I see that objtool is run after each > > compilation. It might be interesting to compare the options that > > are > > passed to objtool in my case and in yours. Mine has: > > ./tools/objtool/objtool check --retpoline --uaccess \ > > arch/x86/kernel/apic/apic.o > > > > (same options for any object file, but I show the one that might be > > faulty in your case). > > > > Maybe "gdb objtool" would allow to learn more (but may need to > > recompile objtool with debug enabled, I'm not sure how to do that) > > > > Pierre > > > > Hi all, > > I've gone back to my skylake and attempted a fresh build of 5.10.14. > I used KBUILD_VERBOSE=1, for objtool I have: > > ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ > arch/x86/kernel/apic/apic.o > > Note that the segfault seems to be happening *before* what you quote > above (in generate, check presumably comes after that). > > The full command leading up to the error (not reformatted, > everything between gcc and apic.c is one line): > > make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ > \ > need-builtin=1 \ > need-modorder=1 > gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Hello, On Wed, 2021-02-10 at 09:52 +0100, Frans de Boer wrote: > On 10/02/2021 02:49, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: > > > Hello, > > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > ../configure --prefix=/usr \ > > > > > > --disable-werror \ > > > > > > --enable-kernel=3.2 \ > > > > > > --enable-stack-protector=strong \ > > > > > > --with-headers=/usr/include \ > > > > > > libc_cv_slibdir=/lib > > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > [...] > > > > > Well I don't need that workaround for using '-march=native - > > > > > O2' on > > > > > my skylake, it booted successfully. Fortunately, Frans said > > > > > it > > > > > works for him, and htat distros are using it, so I guess we > > > > > too > > > > > should use it. > > > > > > > > > > However, there was one problem other than my own typos in > > > > > editing > > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > > make[3]: *** [scripts/Makefile.build:279: > > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > > Exact same problem here (not a memory problem, or very big > > > "cosmic ray"). same problem on kernel-5.10.9 too. > > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > > glibc-2.32 make the segmentation fault (I previously restarted > > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > > compilation was OK). > > > My conclusion, binutils is the trouble maker. > > > Could somebody confirm this finding? > > > Google is mute on this subject but may be my search > > > keywords were not that good. > > > advices? suggestions? > > > > > Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 > > (partly because I'd prefer to use glibc-2.33 because of its iconv > > fixes). > > > > And I'm surprised at 5.10.9 because based on the kernel list and > > binutils-bugs I had thought that would crap out in objcopy (with an > > error message about the sections, not a segfault). > > > > This does sound as if it is a real problem, but I guess the reason > > google is not coming up with anything is that binutils-2.36 and > > 2.36.1 are fresh. Normally we try to keep on the cutting edge > > rather than the bleeding edge, but this time we've maybe overshot. > > > > Just to be clear (before Bruce asks, I know he distrusts using any > > CFLAGS) - are you building with any variant of -march= ? And what > > CPU are you building on ? Intel(R) Core(TM) i7 CPU 970 @ 3.20GH all compilation done within a / tmpfs 40G Recompilation is done in 2 phases, first the tool-chain (automatic make sequence) then recompile everything within the previously builded tool-chain building process is all "all automatic" (> 1000 utilities/tools/applications) duration is around 5 hours. Here is my finding (everything equal beside the glibc binutils version (kernel-5.10.13)) glibc binutils 2.32 2.35.1 compilation successful all the way 2.33 2.36.1 compilation stop at kernel (segmentation fault) kernel is among the last components to be build 2.33 2.35.1 webkitgtk (2.30.4) compilation error, compilation sequence make webkitgtk to be compiled before kernel. (but manual request to compile kernel is successful) 2.32 2.36.1 segmentation fault on kernel compilation (manual request) Manual request about kernel, mean I didn't wait for all packages to be compiled but building context is good enough to have kernel compilation to be successful. At first, I beleived only binutils-2.36.1 was the problem, seems interaction between glibc+binutils are subtle. IMHO: at that stage, modification done to low level components as glibc, binutils should be transparent to a (proved working) building process. So we have; my bet; something fishy, hidden somewhere within both glibc and binutils. could someone else confirm my data with its own experiment? > > I'm still not ready to start my next build, but suddenly I'm even > > less looking forward to it :) > > > > If this is a common problem, I would have though Bruce would have > > seen it when he updated to 2.36 and 2.36.1 - so I assume there is > > some other factor which is not yet obvious. > > > > ĸen > I have rebuild the SysVinit as well as the Systemd version from the > dev > version plus the additional libc... flag for glibc as well as the > extra > flag for binutils. > I had problems before, but after removing the stale CFLAGS variable, > I > could compile everything and successfully booted the resulting images > on > my older but still
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > Hello, > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > ../configure --prefix=/usr \ > > > > --disable-werror \ > > > > --enable-kernel=3.2 \ > > > > --enable-stack-protector=strong \ > > > > --with-headers=/usr/include \ > > > > libc_cv_slibdir=/lib > > > > libc_cv_include_x86_isa_level=no > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > slow > > > > DRAM) and I'm not sure it will get very far before I go to > > > > bed. > > > > My > > > > revised plan is to wait for it to fail, whether that is failign > > > > the > > > > build or failing to boot. > > > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > > > Well I don't need that workaround for using '-march=native -O2' > > > on > > > my skylake, it booted successfully. Fortunately, Frans said it > > > works for him, and htat distros are using it, so I guess we too > > > should use it. > > > > > > However, there was one problem other than my own typos in editing > > > scripts - tried to build linux-5.10.13 - > > > > > > CC arch/x86/kernel/apic/apic.o > > > make[3]: *** [scripts/Makefile.build:279: > > > arch/x86/kernel/apic/apic.o] Segmentation fault > Exact same problem here (not a memory problem, or very big > "cosmic ray"). same problem on kernel-5.10.9 too. > this happen using glibc-2.33 AND binutils-2.36.1 > > rebuilding from scratch using binutils-2.36.1 and keeping > glibc-2.32 make the segmentation fault (I previously restarted > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > compilation was OK). > My conclusion, binutils is the trouble maker. > Could somebody confirm this finding? > Google is mute on this subject but may be my search > keywords were not that good. > advices? suggestions? Since you two are the only ones (among the persons on this list, up to now) who see this, I guess it has something to do with either: - an option in the config, that you use and the others don't - some CFLAGS settings, but I doubt it, because the kernel build system resets them > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > > objtool[402000+11000] > > > followed by a dump of the code bytes. objtool is a kernel thing. According to tools/objtool/Documentation/stack-validation.txt, " The kernel CONFIG_STACK_VALIDATION option enables a host tool named objtool which runs at compile time. It has a "check" subcommand which analyzes every .o file and ensures the validity of its stack metadata. It enforces a set of rules on asm code and C inline assembly code so that stack traces can be reliable. " Note that I do have that option set to y, but maybe other options in the "Compile-time checks and compiler options" may differ... rebuilding with "make V=1", I see that objtool is run after each compilation. It might be interesting to compare the options that are passed to objtool in my case and in yours. Mine has: ./tools/objtool/objtool check --retpoline --uaccess \ arch/x86/kernel/apic/apic.o (same options for any object file, but I show the one that might be faulty in your case). Maybe "gdb objtool" would allow to learn more (but may need to recompile objtool with debug enabled, I'm not sure how to do that) Pierre -- 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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 10/02/2021 02:49, Ken Moffat wrote: On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: Hello, On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: ../configure --prefix=/usr \ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no [...] Well I don't need that workaround for using '-march=native -O2' on my skylake, it booted successfully. Fortunately, Frans said it works for him, and htat distros are using it, so I guess we too should use it. However, there was one problem other than my own typos in editing scripts - tried to build linux-5.10.13 - CC arch/x86/kernel/apic/apic.o make[3]: *** [scripts/Makefile.build:279: arch/x86/kernel/apic/apic.o] Segmentation fault Exact same problem here (not a memory problem, or very big "cosmic ray"). same problem on kernel-5.10.9 too. this happen using glibc-2.33 AND binutils-2.36.1 rebuilding from scratch using binutils-2.36.1 and keeping glibc-2.32 make the segmentation fault (I previously restarted build from scratch with glibc-2.32 + binutils-2.35.1, kernel compilation was OK). My conclusion, binutils is the trouble maker. Could somebody confirm this finding? Google is mute on this subject but may be my search keywords were not that good. advices? suggestions? Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 (partly because I'd prefer to use glibc-2.33 because of its iconv fixes). And I'm surprised at 5.10.9 because based on the kernel list and binutils-bugs I had thought that would crap out in objcopy (with an error message about the sections, not a segfault). This does sound as if it is a real problem, but I guess the reason google is not coming up with anything is that binutils-2.36 and 2.36.1 are fresh. Normally we try to keep on the cutting edge rather than the bleeding edge, but this time we've maybe overshot. Just to be clear (before Bruce asks, I know he distrusts using any CFLAGS) - are you building with any variant of -march= ? And what CPU are you building on ? I'm still not ready to start my next build, but suddenly I'm even less looking forward to it :) If this is a common problem, I would have though Bruce would have seen it when he updated to 2.36 and 2.36.1 - so I assume there is some other factor which is not yet obvious. ĸen I have rebuild the SysVinit as well as the Systemd version from the dev version plus the additional libc... flag for glibc as well as the extra flag for binutils. I had problems before, but after removing the stale CFLAGS variable, I could compile everything and successfully booted the resulting images on my older but still capable Phenom II based system. Same at an older XEON system. --- Frans. -- 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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: > Hello, > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > ../configure --prefix=/usr \ > > > > --disable-werror \ > > > > --enable-kernel=3.2 \ > > > > --enable-stack-protector=strong \ > > > > --with-headers=/usr/include \ > > > > libc_cv_slibdir=/lib > > > > libc_cv_include_x86_isa_level=no > > > > [...] > > > Well I don't need that workaround for using '-march=native -O2' on > > > my skylake, it booted successfully. Fortunately, Frans said it > > > works for him, and htat distros are using it, so I guess we too > > > should use it. > > > > > > However, there was one problem other than my own typos in editing > > > scripts - tried to build linux-5.10.13 - > > > > > > CC arch/x86/kernel/apic/apic.o > > > make[3]: *** [scripts/Makefile.build:279: > > > arch/x86/kernel/apic/apic.o] Segmentation fault > Exact same problem here (not a memory problem, or very big > "cosmic ray"). same problem on kernel-5.10.9 too. > this happen using glibc-2.33 AND binutils-2.36.1 > > rebuilding from scratch using binutils-2.36.1 and keeping > glibc-2.32 make the segmentation fault (I previously restarted > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > compilation was OK). > My conclusion, binutils is the trouble maker. > Could somebody confirm this finding? > Google is mute on this subject but may be my search > keywords were not that good. > advices? suggestions? > Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 (partly because I'd prefer to use glibc-2.33 because of its iconv fixes). And I'm surprised at 5.10.9 because based on the kernel list and binutils-bugs I had thought that would crap out in objcopy (with an error message about the sections, not a segfault). This does sound as if it is a real problem, but I guess the reason google is not coming up with anything is that binutils-2.36 and 2.36.1 are fresh. Normally we try to keep on the cutting edge rather than the bleeding edge, but this time we've maybe overshot. Just to be clear (before Bruce asks, I know he distrusts using any CFLAGS) - are you building with any variant of -march= ? And what CPU are you building on ? I'm still not ready to start my next build, but suddenly I'm even less looking forward to it :) If this is a common problem, I would have though Bruce would have seen it when he updated to 2.36 and 2.36.1 - so I assume there is some other factor which is not yet obvious. ĸ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
Re: [lfs-support] Compile error glibc2.33
On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > ../configure --prefix=/usr\ > > --disable-werror \ > > --enable-kernel=3.2 \ > > --enable-stack-protector=strong \ > > --with-headers=/usr/include \ > > libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no > > > > I've started the native build, but the machine is slow (i3, slow > > DRAM) and I'm not sure it will get very far before I go to bed. My > > revised plan is to wait for it to fail, whether that is failign the > > build or failing to boot. > > > > Assuming it does fail, I'll start again with that workaround. > > > Well I don't need that workaround for using '-march=native -O2' on > my skylake, it booted successfully. Fortunately, Frans said it > works for him, and htat distros are using it, so I guess we too > should use it. > > However, there was one problem other than my own typos in editing > scripts - tried to build linux-5.10.13 - > > CC arch/x86/kernel/apic/apic.o > make[3]: *** [scripts/Makefile.build:279: arch/x86/kernel/apic/apic.o] > Segmentation fault > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: segfault at 70 ip > 0040c13e sp 7ffd0f655670 error 4 in objtool[402000+11000] > followed by a dump of the code bytes. > > Decided to try 5.10.14 just in case, but that failed the same way, > on the same file (freshly extracted 5.10 source, freshly patched to > .14). Then I tried 5.11.0-rc7 and that built without problems. > > My initial guess is that the memory has gone faulty, so I booted > memtest86. That is currently part-way through the second of four > passes, no errors found so far. Maybe it was the old "cosmic rays" > problem, maybe an error will show before memtest86 finishes, or > maybe binutils-2.36.1 still has a problem with something in the > kernel. > > I suppose I'd better go back to updating the rest of my scripts so > that I can try builds on haswell and zen1 with -march=native.+ > Left memtest86 running, all tests ok, but then I noticed it had only used one core (the default). Went back to the CPU options, but both parrallel (all cores) and round robin quickly reported that UEFI had failed to start CPU2. My LFS systems on hat machine use the bios, I suspect the UEFI problem is par for the course on lower-end machines from that date. I then booted the new svn system again (5.11.0-rc7) and tried to build 5.10.13, 5.10.12, 5.10.15-rc1 : all again failed with a segfault. I'll give it another try with the extra libc_cv setting just in case, but probably not for a few days. First, I'm running memtest86 on my oldest ryzen before trying to build that with -march=native -O3 (again, without the additional libc_cv). ĸ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
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Hello, On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > ../configure --prefix=/usr \ > > > --disable-werror \ > > > --enable-kernel=3.2 \ > > > --enable-stack-protector=strong \ > > > --with-headers=/usr/include \ > > > libc_cv_slibdir=/lib > > > libc_cv_include_x86_isa_level=no > > > > > > I've started the native build, but the machine is slow (i3, slow > > > DRAM) and I'm not sure it will get very far before I go to bed. > > > My > > > revised plan is to wait for it to fail, whether that is failign > > > the > > > build or failing to boot. > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > Well I don't need that workaround for using '-march=native -O2' on > > my skylake, it booted successfully. Fortunately, Frans said it > > works for him, and htat distros are using it, so I guess we too > > should use it. > > > > However, there was one problem other than my own typos in editing > > scripts - tried to build linux-5.10.13 - > > > > CC arch/x86/kernel/apic/apic.o > > make[3]: *** [scripts/Makefile.build:279: > > arch/x86/kernel/apic/apic.o] Segmentation fault Exact same problem here (not a memory problem, or very big "cosmic ray"). same problem on kernel-5.10.9 too. this happen using glibc-2.33 AND binutils-2.36.1 rebuilding from scratch using binutils-2.36.1 and keeping glibc-2.32 make the segmentation fault (I previously restarted build from scratch with glibc-2.32 + binutils-2.35.1, kernel compilation was OK). My conclusion, binutils is the trouble maker. Could somebody confirm this finding? Google is mute on this subject but may be my search keywords were not that good. advices? suggestions? > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > objtool[402000+11000] > > followed by a dump of the code bytes. > > > > Decided to try 5.10.14 just in case, but that failed the same way, > > on the same file (freshly extracted 5.10 source, freshly patched to > > .14). Then I tried 5.11.0-rc7 and that built without problems. > > > > My initial guess is that the memory has gone faulty, so I booted > > memtest86. That is currently part-way through the second of four > > passes, no errors found so far. Maybe it was the old "cosmic rays" > > problem, maybe an error will show before memtest86 finishes, or > > maybe binutils-2.36.1 still has a problem with something in the > > kernel. > > > > I suppose I'd better go back to updating the rest of my scripts so > > that I can try builds on haswell and zen1 with -march=native.+ > > > > Left memtest86 running, all tests ok, but then I noticed it had only > used one core (the default). Went back to the CPU options, but both > parrallel (all cores) and round robin quickly reported that UEFI had > failed to start CPU2. My LFS systems on hat machine use the bios, I > suspect the UEFI problem is par for the course on lower-end > machines from that date. > > I then booted the new svn system again (5.11.0-rc7) and tried to > build 5.10.13, 5.10.12, 5.10.15-rc1 : all again failed with a > segfault. I'll give it another try with the extra libc_cv setting > just in case, but probably not for a few days. > > First, I'm running memtest86 on my oldest ryzen before trying to > build that with -march=native -O3 (again, without the additional > libc_cv). > > ĸ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) > -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org -- 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
Re: [lfs-support] Compile error glibc2.33
On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > ../configure --prefix=/usr\ > --disable-werror \ > --enable-kernel=3.2 \ > --enable-stack-protector=strong \ > --with-headers=/usr/include \ > libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no > > I've started the native build, but the machine is slow (i3, slow > DRAM) and I'm not sure it will get very far before I go to bed. My > revised plan is to wait for it to fail, whether that is failign the > build or failing to boot. > > Assuming it does fail, I'll start again with that workaround. > Well I don't need that workaround for using '-march=native -O2' on my skylake, it booted successfully. Fortunately, Frans said it works for him, and htat distros are using it, so I guess we too should use it. However, there was one problem other than my own typos in editing scripts - tried to build linux-5.10.13 - CC arch/x86/kernel/apic/apic.o make[3]: *** [scripts/Makefile.build:279: arch/x86/kernel/apic/apic.o] Segmentation fault Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in objtool[402000+11000] followed by a dump of the code bytes. Decided to try 5.10.14 just in case, but that failed the same way, on the same file (freshly extracted 5.10 source, freshly patched to .14). Then I tried 5.11.0-rc7 and that built without problems. My initial guess is that the memory has gone faulty, so I booted memtest86. That is currently part-way through the second of four passes, no errors found so far. Maybe it was the old "cosmic rays" problem, maybe an error will show before memtest86 finishes, or maybe binutils-2.36.1 still has a problem with something in the kernel. I suppose I'd better go back to updating the rest of my scripts so that I can try builds on haswell and zen1 with -march=native.+ ĸ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
Re: [lfs-support] Compile error glibc2.33
On 08/02/2021 05:05, Bruce Dubbs wrote: On 2/7/21 9:52 PM, Ken Moffat wrote: On Mon, Feb 08, 2021 at 11:14:22AM +0800, xry...@mengyan1223.wang wrote: Please help me to test my glibc workaround in this thread. If it works, crt1.o should have no "needed" ISA markers (even x86-64-baseline should not be there). Then we can add it as a note in the book. If it was on binutils sid, it should be diagnosticed already in the editors' builds. We use -march in GMP and libffi so their test suites would immediately fail, if it was a binutils issue. I think it's not glibc devs, just other packagers or distro maintainers like us thought it was a binutils issue. I actually left a wrong comment in the BZ. No way to delete it :(. Sorry again for the bad formatting on my phone. Thanks for reminding me of that workaround, I'd lost sight of it. To quote you from upthread - | You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". | Just append it to glibc configure line, like: ../configure --prefix=/usr \ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no Just a minor tweak. I had to read this closely to understand it: ../configure --prefix=/usr \ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib \ libc_cv_include_x86_isa_level=no -- Bruce I did not mention it explicitly, but as soon as Xi mentioned the workaround, I tried it. It works on my older system. It also seems that distributors are now also using this workaround. One question I have: where can we find those libc_... switches? I have searched for it before, but could not find it --- Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On Mon, Feb 08, 2021 at 11:14:22AM +0800, xry...@mengyan1223.wang wrote: >Please help me to test my glibc workaround in this thread. If it works, >crt1.o should have no "needed" ISA markers (even x86-64-baseline should >not be there). Then we can add it as a note in the book. >If it was on binutils sid, it should be diagnosticed already in the >editors' builds. We use -march in GMP and libffi so their test suites >would immediately fail, if it was a binutils issue. >I think it's not glibc devs, just other packagers or distro maintainers >like us thought it was a binutils issue. I actually left a wrong comment >in the BZ. No way to delete it :(. >Sorry again for the bad formatting on my phone. Thanks for reminding me of that workaround, I'd lost sight of it. To quote you from upthread - | You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". | Just append it to glibc configure line, like: ../configure --prefix=/usr\ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no I've started the native build, but the machine is slow (i3, slow DRAM) and I'm not sure it will get very far before I go to bed. My revised plan is to wait for it to fail, whether that is failign the build or failing to boot. Assuming it does fail, I'll start again with that workaround. ĸ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
Re: [lfs-support] Compile error glibc2.33
On Mon, Feb 08, 2021 at 10:25:27AM +0800, Xi Ruoyao wrote: > On 2021-02-07 18:43 +, 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?
Re: [lfs-support] Compile error glibc2.33
On 2/7/21 9:52 PM, Ken Moffat wrote: On Mon, Feb 08, 2021 at 11:14:22AM +0800, xry...@mengyan1223.wang wrote: Please help me to test my glibc workaround in this thread. If it works, crt1.o should have no "needed" ISA markers (even x86-64-baseline should not be there). Then we can add it as a note in the book. If it was on binutils sid, it should be diagnosticed already in the editors' builds. We use -march in GMP and libffi so their test suites would immediately fail, if it was a binutils issue. I think it's not glibc devs, just other packagers or distro maintainers like us thought it was a binutils issue. I actually left a wrong comment in the BZ. No way to delete it :(. Sorry again for the bad formatting on my phone. Thanks for reminding me of that workaround, I'd lost sight of it. To quote you from upthread - | You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". | Just append it to glibc configure line, like: ../configure --prefix=/usr\ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no Just a minor tweak. I had to read this closely to understand it: ../configure --prefix=/usr\ --disable-werror\ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib\ libc_cv_include_x86_isa_level=no -- Bruce -- 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
Re: [lfs-support] Compile error glibc2.33
Please help me to test my glibc workaround in this thread. If it works, crt1.o should have no "needed" ISA markers (even x86-64-baseline should not be there). Then we can add it as a note in the book. If it was on binutils sid, it should be diagnosticed already in the editors' builds. We use -march in GMP and libffi so their test suites would immediately fail, if it was a binutils issue.I think it's not glibc devs, just other packagers or distro maintainers like us thought it was a binutils issue. I actually left a wrong comment in the BZ. No way to delete it :(. Sorry again for the bad formatting on my phone. -- 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
Re: [lfs-support] Compile error glibc2.33
On 2021-02-07 18:43 +, 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. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- 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
Re: [lfs-support] Compile error glibc2.33
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
Re: [lfs-support] Compile error glibc2.33
On 2021-02-06 15:51 +0100, Frans de Boer wrote: > On 06/02/2021 15:46, Xi Ruoyao wrote: > > On 2021-02-06 14:56 +0100, Frans de Boer wrote: > > > On 06/02/2021 14:34, Pierre Labastie wrote: > > > > On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: > > > > > On 05/02/2021 21:35, Pierre Labastie wrote: > > > > > > On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: > > > > > > > On 05/02/2021 20:16, Frans de Boer wrote: > > > > > > > > > > > > > > > > > > > > > > > On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Frans, > > > > > > > > > > > > > > > > > > Could you send the result of > > > > > > > > > > > > > > > > > > $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA > > > > > > > > > > > > > > > > The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' > > > > > > > returns > > > > > > > nothing. > > > > > > You need to use readelf from binutils 2.36. If you have back up to > > > > > > 2.35.1, it returns nothing. > > > > > > > > > > > > Pierre > > > > > > > > > > > Okay, I have recompiled ch5, ch6 and ch7 as well as up to and > > > > > including > > > > > glibc-2.33 and using binutils-2.36. > > > > > Attached is the result of that latest config.log (ch8). Other results > > > > > are found in previous messages. > > > > > > > > > > Also, the output of readelf in ch8: > > > > > Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64- > > > > > v3 > > > > > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 > > > > AFAICT, no one among the editors have the first line. Only baseline is > > > > "needed", not v2 nor v3, although we have more recent CPUs. I cannot > > > > tell how this "needed" line is determined, but I see in config.log you > > > > have -march=native. Maybe you could try without any CFLAGS, and check > > > > that you do not have the v2 and v3 in "needed". > > > > > > > > BTW, you say you have the warning, but it does not stop the build does > > > > it? Everyone seems to have the warning in a couple of tests in binutils > > > > chapter 8 (ld tests). > > > > > with as contrast to the ch5 output: > > > > > Properties: x86 ISA needed: x86-64-baseline > > > > > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 > > > > > > > > > > However, still getting the next message during testing. > > > > > '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is > > > > > lower > > > > > than required' > > > > > > > > > > After the tests and install, I get the ISA message with everything I > > > > > do. > > > > > Maybe the x86_64-baseline is not the original baseline anymore, > > > > > thereby > > > > > making my processor and many others obsolete according to the glibc > > > > > devs? > > > > > Maybe adding --with-CPU to the configuration might help? > > > > Well, as said above, try without flags. Then you could add them one by > > > > one... > > > > > > > > Pierre > > > > > > > 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". > I did not mentioned a fight or anything in that order. Just that this is > in line with other recent trends of trying to ignore older - but still > capable - processors and the current worldwide installed base. You can turn off ISA marker with "libc_cv_include_x86_isa_level=no". Just append it to glibc configure line, like: ../configure --prefix=/usr\ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no Add back -march=native and it should be OK. Upstream will apply a patch like https://sourceware.org/pipermail/libc-alpha/attachments/20210203/2fcbcba5/attachment-0001.bin to automatically set libc_cv_include_x86_isa_level=no for -march settings where the ISA marker does not make sense (like your case). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University --
Re: [lfs-support] Compile error glibc2.33
On 06/02/2021 15:46, Xi Ruoyao wrote: On 2021-02-06 14:56 +0100, Frans de Boer wrote: On 06/02/2021 14:34, Pierre Labastie wrote: On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Okay, I have recompiled ch5, ch6 and ch7 as well as up to and including glibc-2.33 and using binutils-2.36. Attached is the result of that latest config.log (ch8). Other results are found in previous messages. Also, the output of readelf in ch8: Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 AFAICT, no one among the editors have the first line. Only baseline is "needed", not v2 nor v3, although we have more recent CPUs. I cannot tell how this "needed" line is determined, but I see in config.log you have -march=native. Maybe you could try without any CFLAGS, and check that you do not have the v2 and v3 in "needed". BTW, you say you have the warning, but it does not stop the build does it? Everyone seems to have the warning in a couple of tests in binutils chapter 8 (ld tests). with as contrast to the ch5 output: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 However, still getting the next message during testing. '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is lower than required' After the tests and install, I get the ISA message with everything I do. Maybe the x86_64-baseline is not the original baseline anymore, thereby making my processor and many others obsolete according to the glibc devs? Maybe adding --with-CPU to the configuration might help? Well, as said above, try without flags. Then you could add them one by one... Pierre 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". I did not mentioned a fight or anything in that order. Just that this is in line with other recent trends of trying to ignore older - but still capable - processors and the current worldwide installed base. Frans. -- 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
Re: [lfs-support] Compile error glibc2.33 (SOLVED more or less)
On 06/02/2021 14:34, Pierre Labastie wrote: On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Okay, I have recompiled ch5, ch6 and ch7 as well as up to and including glibc-2.33 and using binutils-2.36. Attached is the result of that latest config.log (ch8). Other results are found in previous messages. Also, the output of readelf in ch8: Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 AFAICT, no one among the editors have the first line. Only baseline is "needed", not v2 nor v3, although we have more recent CPUs. I cannot tell how this "needed" line is determined, but I see in config.log you have -march=native. Maybe you could try without any CFLAGS, and check that you do not have the v2 and v3 in "needed". BTW, you say you have the warning, but it does not stop the build does it? Everyone seems to have the warning in a couple of tests in binutils chapter 8 (ld tests). with as contrast to the ch5 output: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 However, still getting the next message during testing. '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is lower than required' After the tests and install, I get the ISA message with everything I do. Maybe the x86_64-baseline is not the original baseline anymore, thereby making my processor and many others obsolete according to the glibc devs? Maybe adding --with-CPU to the configuration might help? Well, as said above, try without flags. Then you could add them one by one... Pierre Okay, long ago I added these compiler flags, removed them when compiling the new ch7, but forgot last year to remove them for the chroot script for ch8 and later. Still not an optimized compile, but at least I can move on. Knowing that this might not last either depending upon the devs wimps. Also, the output of readelf is now also: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On 2021-02-06 14:56 +0100, Frans de Boer wrote: > On 06/02/2021 14:34, Pierre Labastie wrote: > > On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: > > > On 05/02/2021 21:35, Pierre Labastie wrote: > > > > On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: > > > > > On 05/02/2021 20:16, Frans de Boer wrote: > > > > > > > > > > > > > > > > > On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: > > > > > > > > > > > > > > > > > > > > Hi Frans, > > > > > > > > > > > > > > Could you send the result of > > > > > > > > > > > > > > $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA > > > > > > > > > > > > The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' > > > > > returns > > > > > nothing. > > > > You need to use readelf from binutils 2.36. If you have back up to > > > > 2.35.1, it returns nothing. > > > > > > > > Pierre > > > > > > > Okay, I have recompiled ch5, ch6 and ch7 as well as up to and > > > including > > > glibc-2.33 and using binutils-2.36. > > > Attached is the result of that latest config.log (ch8). Other results > > > are found in previous messages. > > > > > > Also, the output of readelf in ch8: > > > Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 > > > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 > > AFAICT, no one among the editors have the first line. Only baseline is > > "needed", not v2 nor v3, although we have more recent CPUs. I cannot > > tell how this "needed" line is determined, but I see in config.log you > > have -march=native. Maybe you could try without any CFLAGS, and check > > that you do not have the v2 and v3 in "needed". > > > > BTW, you say you have the warning, but it does not stop the build does > > it? Everyone seems to have the warning in a couple of tests in binutils > > chapter 8 (ld tests). > > > with as contrast to the ch5 output: > > > Properties: x86 ISA needed: x86-64-baseline > > > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 > > > > > > However, still getting the next message during testing. > > > '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is > > > lower > > > than required' > > > > > > After the tests and install, I get the ISA message with everything I > > > do. > > > Maybe the x86_64-baseline is not the original baseline anymore, > > > thereby > > > making my processor and many others obsolete according to the glibc > > > devs? > > > Maybe adding --with-CPU to the configuration might help? > > Well, as said above, try without flags. Then you could add them one by > > one... > > > > Pierre > > > 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". -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- 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
Re: [lfs-support] Compile error glibc2.33
On 06/02/2021 14:34, Pierre Labastie wrote: On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Okay, I have recompiled ch5, ch6 and ch7 as well as up to and including glibc-2.33 and using binutils-2.36. Attached is the result of that latest config.log (ch8). Other results are found in previous messages. Also, the output of readelf in ch8: Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 AFAICT, no one among the editors have the first line. Only baseline is "needed", not v2 nor v3, although we have more recent CPUs. I cannot tell how this "needed" line is determined, but I see in config.log you have -march=native. Maybe you could try without any CFLAGS, and check that you do not have the v2 and v3 in "needed". BTW, you say you have the warning, but it does not stop the build does it? Everyone seems to have the warning in a couple of tests in binutils chapter 8 (ld tests). with as contrast to the ch5 output: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 However, still getting the next message during testing. '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is lower than required' After the tests and install, I get the ISA message with everything I do. Maybe the x86_64-baseline is not the original baseline anymore, thereby making my processor and many others obsolete according to the glibc devs? Maybe adding --with-CPU to the configuration might help? Well, as said above, try without flags. Then you could add them one by one... Pierre I will try that as a last resort. Have not read your previous suggestion completely ;) -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On 06/02/2021 14:34, Pierre Labastie wrote: On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Okay, I have recompiled ch5, ch6 and ch7 as well as up to and including glibc-2.33 and using binutils-2.36. Attached is the result of that latest config.log (ch8). Other results are found in previous messages. Also, the output of readelf in ch8: Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 AFAICT, no one among the editors have the first line. Only baseline is "needed", not v2 nor v3, although we have more recent CPUs. I cannot tell how this "needed" line is determined, but I see in config.log you have -march=native. Maybe you could try without any CFLAGS, and check that you do not have the v2 and v3 in "needed". BTW, you say you have the warning, but it does not stop the build does it? Everyone seems to have the warning in a couple of tests in binutils chapter 8 (ld tests). with as contrast to the ch5 output: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 However, still getting the next message during testing. '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is lower than required' After the tests and install, I get the ISA message with everything I do. Maybe the x86_64-baseline is not the original baseline anymore, thereby making my processor and many others obsolete according to the glibc devs? Maybe adding --with-CPU to the configuration might help? Well, as said above, try without flags. Then you could add them one by one... Pierre 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!! Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On Sat, 2021-02-06 at 13:43 +0100, Frans de Boer wrote: > On 05/02/2021 21:35, Pierre Labastie wrote: > > On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: > > > On 05/02/2021 20:16, Frans de Boer wrote: > > > > > > > > > > > On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: > > > > > > > > > > > > > > Hi Frans, > > > > > > > > > > Could you send the result of > > > > > > > > > > $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA > > > > > > > > The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' > > > returns > > > nothing. > > You need to use readelf from binutils 2.36. If you have back up to > > 2.35.1, it returns nothing. > > > > Pierre > > > Okay, I have recompiled ch5, ch6 and ch7 as well as up to and > including > glibc-2.33 and using binutils-2.36. > Attached is the result of that latest config.log (ch8). Other results > are found in previous messages. > > Also, the output of readelf in ch8: > Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 AFAICT, no one among the editors have the first line. Only baseline is "needed", not v2 nor v3, although we have more recent CPUs. I cannot tell how this "needed" line is determined, but I see in config.log you have -march=native. Maybe you could try without any CFLAGS, and check that you do not have the v2 and v3 in "needed". BTW, you say you have the warning, but it does not stop the build does it? Everyone seems to have the warning in a couple of tests in binutils chapter 8 (ld tests). > > with as contrast to the ch5 output: > Properties: x86 ISA needed: x86-64-baseline > x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 > > However, still getting the next message during testing. > '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is > lower > than required' > > After the tests and install, I get the ISA message with everything I > do. > Maybe the x86_64-baseline is not the original baseline anymore, > thereby > making my processor and many others obsolete according to the glibc > devs? > Maybe adding --with-CPU to the configuration might help? Well, as said above, try without flags. Then you could add them one by one... Pierre -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Okay, I have recompiled ch5, ch6 and ch7 as well as up to and including glibc-2.33 and using binutils-2.36. Attached is the result of that latest config.log (ch8). Other results are found in previous messages. Also, the output of readelf in ch8: Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3 x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 with as contrast to the ch5 output: Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 However, still getting the next message during testing. '/sources-base/glibc-2.33/glibc-build/libc.so.6: CPU ISA level is lower than required' After the tests and install, I get the ISA message with everything I do. Maybe the x86_64-baseline is not the original baseline anymore, thereby making my processor and many others obsolete according to the glibc devs? Maybe adding --with-CPU to the configuration might help? Frans -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.69. Invocation command line was $ /sources-base/glibc-2.33/configure --prefix=/usr --libdir=/usr/lib --disable-werror --enable-kernel=3.2 --enable-stack-protector=strong --with-headers=/usr/include libc_cv_slibdir=/lib ## - ## ## Platform. ## ## - ## hostname = pws1 uname -m = x86_64 uname -r = 5.8.18-FdB-pws1 uname -s = Linux uname -v = #2 SMP Fri Jan 29 22:05:14 CET 2021 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin ## --- ## ## Core tests. ## ## --- ## configure:2213: checking build system type configure:2227: result: x86_64-pc-linux-gnu configure:2247: checking host system type configure:2260: result: x86_64-pc-linux-gnu configure:2329: checking for gcc configure:2345: found /usr/bin/gcc configure:2356: result: gcc configure:2585: checking for C compiler version configure:2594: gcc --version >&5 gcc (GCC) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2605: $? = 0 configure:2594: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-cross-linux-gnu/10.2.0/lto-wrapper Target: x86_64-cross-linux-gnu Configured with: /mnt/lfs/sources-base/gcc-10.2.0/configure --prefix=/usr --host=x86_64-cross-linux-gnu --build=x86_64-suse-linux-gnu CC_FOR_TARGET=x86_64-cross-linux-gnu-gcc --with-build-sysroot=/mnt/lfs --enable-initfine-array --enable-languages=c,c++ --disable-multilib --disable-nls --disable-decimal-float --disable-libatomic --disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv --disable-libstdcxx Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) configure:2605: $? = 0 configure:2594: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2594: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2610: checking for suffix of object files configure:2632: gcc -c -O2 -march=native conftest.c >&5 configure:2636: $? = 0 configure:2657: result: o configure:2661: checking whether we are using the GNU C compiler configure:2680: gcc -c -O2 -march=native conftest.c >&5 configure:2680: $? = 0 configure:2689: result: yes configure:2698: checking whether gcc accepts -g configure:2718: gcc -c -g conftest.c >&5 configure:2718: $? = 0 configure:2759: result: yes configure:2879: checking
Re: [lfs-support] Compile error glibc2.33
On Fri, Feb 05, 2021 at 08:36:45PM +0100, Frans de Boer wrote: > On 05/02/2021 20:16, Frans de Boer wrote: > > On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: > > > Hi Frans, > > > > > > Could you send the result of > > > > > > $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA > > > > > > (in host distro) > > > > > > and config.log of glibc (both ch6 and ch8)? > > > > > > Sorry for bad formating (using my phone to reply) > > > > > Just started recompiling glibc 2.33 (ch8) after change to binutils > > 2.35.2. Ik keep you informed using this list. > > > > Frans > Okay, I get the same message when compiling with binutils 2.35.2. > Hi Frans, sorry my suggestion has delayed you getting closer to the problem. For the little it is worth, I've just tried building glibc-2.33 on a zen1 (so, it is unlikely to replicate your error) in a completed system with binutils-2.35.1, headers from linux-5.9 and running a 5.10.2 kernel. That sailed through, but with one error in the glibc tests: FAIL: elf/tst-cpu-features-cpuinfo I guess that means glibc-2.36 is needed to use the new HWCAPS abilities when building binaries (no other failures, but this is on a completed system, not in chroot). And I must admit I'm surprised DESTDIR works, I thought glibc used to required a different variation (INSTALL_ROOT or something like that). I'll go back to rebuilding my firefoxes (built 86.0b5 last night for testing, but that too had the vulnerability, 86.0b6 has had the fix) and looking at security advisories ;-) ĸ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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 22:23, Frans de Boer wrote: On 05/02/2021 21:54, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Now recompiling with binutils-2.36 and glibc-2.33. I will later send the config.log from ch5 (not ch6) and tomorrow morning (UTC-1) the config.log from ch8. Frans. glibc-2.33 config.log from ch5. Maybe later the result from readelf, otherwise tomorrow. Frans. Quicker then expected: The result from readelf after glibc-2.33 in ch5. Properties: x86 ISA needed: x86-64-baseline x86 ISA used: x86-64-baseline, x86-64-v2, x86-64-v3, x86-64-v4 Frans. -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 21:54, Frans de Boer wrote: On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Now recompiling with binutils-2.36 and glibc-2.33. I will later send the config.log from ch5 (not ch6) and tomorrow morning (UTC-1) the config.log from ch8. Frans. glibc-2.33 config.log from ch5. Maybe later the result from readelf, otherwise tomorrow. Frans. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.69. Invocation command line was $ /mnt/lfs/sources-base/glibc-2.33/configure --prefix=/usr --host=x86_64-cross-linux-gnu --build=x86_64-suse-linux-gnu --enable-kernel=3.2 --with-headers=/mnt/lfs/usr/include libc_cv_slibdir=/lib ## - ## ## Platform. ## ## - ## hostname = pws1 uname -m = x86_64 uname -r = 5.8.18-FdB-pws1 uname -s = Linux uname -v = #2 SMP Fri Jan 29 22:05:14 CET 2021 /usr/bin/uname -p = x86_64 /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /mnt/lfs/crosstools/bin PATH: /bin PATH: /usr/bin ## --- ## ## Core tests. ## ## --- ## configure:2213: checking build system type configure:2227: result: x86_64-suse-linux-gnu configure:2247: checking host system type configure:2260: result: x86_64-cross-linux-gnu configure:2289: checking for x86_64-cross-linux-gnu-gcc configure:2305: found /mnt/lfs/crosstools/bin/x86_64-cross-linux-gnu-gcc configure:2316: result: x86_64-cross-linux-gnu-gcc configure:2585: checking for C compiler version configure:2594: x86_64-cross-linux-gnu-gcc --version >&5 x86_64-cross-linux-gnu-gcc (GCC) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2605: $? = 0 configure:2594: x86_64-cross-linux-gnu-gcc -v >&5 Using built-in specs. COLLECT_GCC=x86_64-cross-linux-gnu-gcc COLLECT_LTO_WRAPPER=/mnt/lfs/crosstools/libexec/gcc/x86_64-cross-linux-gnu/10.2.0/lto-wrapper Target: x86_64-cross-linux-gnu Configured with: /mnt/lfs/sources-base/gcc-10.2.0/configure --prefix=/mnt/lfs/crosstools --target=x86_64-cross-linux-gnu --with-sysroot=/mnt/lfs --with-glibc-version=2.19 --with-newlib --without-headers --enable-initfini-array --disable-shared --disable-decimal-float --disable-libatomic --disable-libgomp --disable-libquadmath --disable-libssp --disable-libstdcxx --disable-libvtv --disable-multilib --disable-nls --disable-threads --enable-languages=c,c++ Thread model: single Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) configure:2605: $? = 0 configure:2594: x86_64-cross-linux-gnu-gcc -V >&5 x86_64-cross-linux-gnu-gcc: error: unrecognized command-line option '-V' x86_64-cross-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2594: x86_64-cross-linux-gnu-gcc -qversion >&5 x86_64-cross-linux-gnu-gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? x86_64-cross-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2610: checking for suffix of object files configure:2632: x86_64-cross-linux-gnu-gcc -c conftest.c >&5 configure:2636: $? = 0 configure:2657: result: o configure:2661: checking whether we are using the GNU C compiler configure:2680: x86_64-cross-linux-gnu-gcc -c conftest.c >&5 configure:2680: $? = 0 configure:2689: result: yes configure:2698: checking whether x86_64-cross-linux-gnu-gcc accepts -g configure:2718: x86_64-cross-linux-gnu-gcc -c -g conftest.c >&5 configure:2718: $? = 0 configure:2759: result: yes configure:2788: checking for gcc configure:2804: found /usr/bin/gcc configure:2815: result: gcc configure:2839: checking for x86_64-cross-linux-gnu-readelf configure:2855: found /mnt/lfs/crosstools/bin/x86_64-cross-linux-gnu-readelf configure:2866: result: x86_64-cross-linux-gnu-readelf configure:2944: checking for x86_64-cross-linux-gnu-g++ configure:2960: found /mnt/lfs/crosstools/bin/x86_64-cross-linux-gnu-g++ configure:2971: result: x86_64-cross-linux-gnu-g++ configure:3042: checking for C++ compiler version configure:3051: x86_64-cross-linux-gnu-g++ --version >&5 x86_64-cross-linux-gnu-g++ (GCC)
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 21:35, Pierre Labastie wrote: On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre Now recompiling with binutils-2.36 and glibc-2.33. I will later send the config.log from ch5 (not ch6) and tomorrow morning (UTC-1) the config.log from ch8. Frans. -- 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
Re: [lfs-support] Compile error glibc2.33
On Fri, 2021-02-05 at 20:54 +0100, Frans de Boer wrote: > On 05/02/2021 20:16, Frans de Boer wrote: > > > > > On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: > > > > > > > > Hi Frans, > > > > > > Could you send the result of > > > > > > $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA > > > > The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns > nothing. You need to use readelf from binutils 2.36. If you have back up to 2.35.1, it returns nothing. Pierre -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA (in host distro) and config.log of glibc (both ch6 and ch8)? Sorry for bad formating (using my phone to reply) Just started recompiling glibc 2.33 (ch8) after change to binutils 2.35.2. Ik keep you informed using this list. Frans The line '$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA' returns nothing. -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 20:16, Frans de Boer wrote: On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA (in host distro) and config.log of glibc (both ch6 and ch8)? Sorry for bad formating (using my phone to reply) Just started recompiling glibc 2.33 (ch8) after change to binutils 2.35.2. Ik keep you informed using this list. Frans Okay, I get the same message when compiling with binutils 2.35.2. I will now restart the rebuild. In the meantime, I have already attached the config.log from ch8. Frans. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.69. Invocation command line was $ /sources-base/glibc-2.33/configure --prefix=/usr --libdir=/usr/lib --disable-werror --enable-kernel=3.2 --enable-stack-protector=strong --with-headers=/usr/include libc_cv_slibdir=/lib ## - ## ## Platform. ## ## - ## hostname = pws1 uname -m = x86_64 uname -r = 5.8.18-FdB-pws1 uname -s = Linux uname -v = #2 SMP Fri Jan 29 22:05:14 CET 2021 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin ## --- ## ## Core tests. ## ## --- ## configure:2213: checking build system type configure:2227: result: x86_64-pc-linux-gnu configure:2247: checking host system type configure:2260: result: x86_64-pc-linux-gnu configure:2329: checking for gcc configure:2345: found /usr/bin/gcc configure:2356: result: gcc configure:2585: checking for C compiler version configure:2594: gcc --version >&5 gcc (GCC) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2605: $? = 0 configure:2594: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-cross-linux-gnu/10.2.0/lto-wrapper Target: x86_64-cross-linux-gnu Configured with: /mnt/lfs/sources-base/gcc-10.2.0/configure --prefix=/usr --host=x86_64-cross-linux-gnu --build=x86_64-suse-linux-gnu CC_FOR_TARGET=x86_64-cross-linux-gnu-gcc --with-build-sysroot=/mnt/lfs --enable-initfine-array --enable-languages=c,c++ --disable-multilib --disable-nls --disable-decimal-float --disable-libatomic --disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv --disable-libstdcxx Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) configure:2605: $? = 0 configure:2594: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2594: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:2605: $? = 1 configure:2610: checking for suffix of object files configure:2632: gcc -c -O2 -march=native conftest.c >&5 configure:2636: $? = 0 configure:2657: result: o configure:2661: checking whether we are using the GNU C compiler configure:2680: gcc -c -O2 -march=native conftest.c >&5 configure:2680: $? = 0 configure:2689: result: yes configure:2698: checking whether gcc accepts -g configure:2718: gcc -c -g conftest.c >&5 configure:2718: $? = 0 configure:2759: result: yes configure:2879: checking for readelf configure:2895: found /usr/bin/readelf configure:2906: result: readelf configure:2988: checking for g++ configure:3004: found /usr/bin/g++ configure:3015: result: g++ configure:3042: checking for C++ compiler version configure:3051: g++ --version >&5 g++ (GCC) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3062: $? = 0 configure:3051: g++ -v >&5 Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-cross-linux-gnu/10.2.0/lto-wrapper Target: x86_64-cross-linux-gnu Configured with: /mnt/lfs/sources-base/gcc-10.2.0/configure --prefix=/usr --host=x86_64-cross-linux-gnu --build=x86_64-suse-linux-gnu CC_FOR_TARGET=x86_64-cross-linux-gnu-gcc --with-build-sysroot=/mnt/lfs --enable-initfine-array --enable-languages=c,c++ --disable-multilib --disable-nls --disable-decimal-float --disable-libatomic --disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv --disable-libstdcxx Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) configure:3062: $? = 0
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 16:25, xry...@mengyan1223.wang wrote: Hi Frans, Could you send the result of $LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA (in host distro) and config.log of glibc (both ch6 and ch8)? Sorry for bad formating (using my phone to reply) Just started recompiling glibc 2.33 (ch8) after change to binutils 2.35.2. Ik keep you informed using this list. Frans -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On Fri, Feb 05, 2021 at 12:31:56PM +0100, Frans de Boer wrote: > On 05/02/2021 12:29, Frans de Boer wrote: > > After the 'file' issue, I started rebuilding LFS. Just to find out that > > it stops with the message > > '/lib/libc.so.6: CPU ISA level is lower than required' > > > > I use a Phenom II X4 365, but that seems now outdated? > > > > --- Frans > > > Sorry, have to add that it was in chapter 8. > Seems to come from the HWCAPS additions (which are supposed to allow distros to produce binaries for various groups of the x86_64 architecture (V1, V2, ...). The tests are supposed to allow the required version to be tested (I can't find a list of versions, but higher versions have more shinier options). I also can't find how to determine what version is requested, nor what version binutils thinks the running machine is. Your machine is from the K10 family, from a little over 10 years ago. I very much doubt that anyone has tried building glibc-2.33 on anything like that. Sounds like a bug somewhere, probably in binutils. I was skimming a mirror of the kernel lists and saw someone having problems with binutils-2.36 (couldn't build 5.10 kernels). The current bugs seems to be listed at https://www.mail-archive.com/bug-binutils@gnu.org/ although I have not attempted to review how serious most of those are. The one I noted (hopefully fixed with 5.10.13) is copied there: https://www.mail-archive.com/bug-binutils@gnu.org/msg36912.html. I get the impression that 2.36 might be problematic. ĸ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
Re: [lfs-support] Compile error glibc2.33
Hi Frans, Could you send the result of$LFS_TGT-readelf -a $LFS/lib/libc.so.6 | grep ISA(in host distro) and config.log of glibc (both ch6 and ch8)?Sorry for bad formating (using my phone to reply) -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 13:42, Ken Moffat wrote: On Fri, Feb 05, 2021 at 12:31:56PM +0100, Frans de Boer wrote: On 05/02/2021 12:29, Frans de Boer wrote: After the 'file' issue, I started rebuilding LFS. Just to find out that it stops with the message '/lib/libc.so.6: CPU ISA level is lower than required' I use a Phenom II X4 365, but that seems now outdated? --- Frans Sorry, have to add that it was in chapter 8. Seems to come from the HWCAPS additions (which are supposed to allow distros to produce binaries for various groups of the x86_64 architecture (V1, V2, ...). The tests are supposed to allow the required version to be tested (I can't find a list of versions, but higher versions have more shinier options). I also can't find how to determine what version is requested, nor what version binutils thinks the running machine is. Your machine is from the K10 family, from a little over 10 years ago. I very much doubt that anyone has tried building glibc-2.33 on anything like that. Sounds like a bug somewhere, probably in binutils. I was skimming a mirror of the kernel lists and saw someone having problems with binutils-2.36 (couldn't build 5.10 kernels). The current bugs seems to be listed at https://www.mail-archive.com/bug-binutils@gnu.org/ although I have not attempted to review how serious most of those are. The one I noted (hopefully fixed with 5.10.13) is copied there: https://www.mail-archive.com/bug-binutils@gnu.org/msg36912.html. I get the impression that 2.36 might be problematic. ĸen Okay, I will just rebuild stuff with binutils-2.35.2 and see if your theory sticks. Just have to wait some time. --- Frans. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
Re: [lfs-support] Compile error glibc2.33
On 05/02/2021 12:29, Frans de Boer wrote: After the 'file' issue, I started rebuilding LFS. Just to find out that it stops with the message '/lib/libc.so.6: CPU ISA level is lower than required' I use a Phenom II X4 365, but that seems now outdated? --- Frans Sorry, have to add that it was in chapter 8. -- A: Yes, just like thatA: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -- 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
