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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On Wed, Feb 10, 2021 at 10:06:22PM +, Roger wrote: > On Wed, 10 Feb 2021 20:04:10 +, Ken Moffat > wrote: > > >The segfault is in objtool (see my reply to Pierre) and the output > >object file got deleted. I was using 5.14.1, my gzipped config, > >objtool and core dump are now at > >http://www.linuxfromscratch.org/~ken/tmp/ > > Using your config I get a seg fault at > arch/x86/kernel/apic/apic.o which is interesting because earlier > I did a "make x86_64_defconfig" and there was no seg fault. In > fact the compilation finished without error. > -- > Roger > Years ago, I learned that the defconfig target was only likely to be useful if you had the same hardware as Linus. Since then, I think that defconfigs get updated much less - new additions should not be enabled by default (although options to enable them, such as the reworking of net drivers, and more recently perhaps some setting to make LED drivers visible) are allowed and other things get pulled in as dependencies which turn out to be hard to turn off. Thanks for trying my config. ĸ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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On Wed, Feb 10, 2021 at 09:58:54PM +0100, Pierre Labastie wrote: > On Wed, 2021-02-10 at 20:04 +, Ken Moffat wrote: > > The segfault is in objtool (see my reply to Pierre) and the output > > object file got deleted. I was using 5.14.1, my gzipped config, > > objtool and core dump are now at > > http://www.linuxfromscratch.org/~ken/tmp/ > > > > The core file returns "access denied". But maybe I do not need it, > because with your config, the bug occurs also on my machine. > Will try to investigate... > Oh, sorry, didn't realise it was mode 600, now changed if anyone else wants it, although since you can recreate the problem, probably not. What really puzzles me is that 5.11-rc7 built fine, allowing me to boot the new system. But even with 5.10.15-rc1 (now released as 5.10.15) the problem remained and I had the impression Greg KH was accelerating the movement of changes in Linus's tree to stable. ĸ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
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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
O Wed, Feb 10, 2021 at 11:43:24PM +0800, Xi Ruoyao wrote: > On 2021-02-10 10:05 -0500, Jean-Marc Pigeon wrote: > > Hello, > > On Wed, 2021-02-10 at 09:52 +0100, Frans de Boer wrote: > > On 10/02/2021 02:49, Ken Moffat wrote: Even objtool (792K) is too big an attachment for the list. I figured the 50M core dump would be, but didn't realise that the limit is 300K. > > > 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? > > > > [...] > > > > > > 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 > > So for you it is an early intel, for me it is a low-end skylake. > > 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.1webkitgtk (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? > > Could you attach the segfaulted executable and its coredump file on segfault > here? Bruce, Pierre, and I tried multiple ways to reproduce the issue but we > couldn't. > The segfault is in objtool (see my reply to Pierre) and the output object file got deleted. I was using 5.14.1, my gzipped config, objtool and core dump are now at http://www.linuxfromscratch.org/~ken/tmp/ ĸ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) --
Re: [lfs-support] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On Wed, 10 Feb 2021 20:04:10 +, Ken Moffat wrote: >The segfault is in objtool (see my reply to Pierre) and the output >object file got deleted. I was using 5.14.1, my gzipped config, >objtool and core dump are now at >http://www.linuxfromscratch.org/~ken/tmp/ Using your config I get a seg fault at arch/x86/kernel/apic/apic.o which is interesting because earlier I did a "make x86_64_defconfig" and there was no seg fault. In fact the compilation finished without error. -- Roger -- 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, 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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On Wed, 2021-02-10 at 21:58 +0100, Pierre Labastie wrote: > On Wed, 2021-02-10 at 20:04 +, Ken Moffat wrote: > > The segfault is in objtool (see my reply to Pierre) and the output > > object file got deleted. I was using 5.14.1, my gzipped config, > > objtool and core dump are now at > > http://www.linuxfromscratch.org/~ken/tmp/ > > > > The core file returns "access denied". But maybe I do not need it, > because with your config, the bug occurs also on my machine. > Will try to investigate... > > Note to Jean-Marc: it may be a bug in binutils, glibc, or in the > kernel, exposed by the binutils or glibc. Agreed could a trouble in kernel too (shown by binutils), as far I can tell, binutils -> kernel compilation segfault. (glibc 2.32 and binutils-2.36.1 with kernel compilation fault) > > Pierre > -- 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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On Wed, 2021-02-10 at 20:04 +, Ken Moffat wrote: > The segfault is in objtool (see my reply to Pierre) and the output > object file got deleted. I was using 5.14.1, my gzipped config, > objtool and core dump are now at > http://www.linuxfromscratch.org/~ken/tmp/ > The core file returns "access denied". But maybe I do not need it, because with your config, the bug occurs also on my machine. Will try to investigate... Note to Jean-Marc: it may be a bug in binutils, glibc, or in the kernel, exposed by the binutils or glibc. 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] Compiling M4 on GCC 10.2
Am 10.02.21 um 16:04 schrieb Xi Ruoyao:
On 2021-02-10 14:16 +0100, Viktor Engelmann wrote:
Am 09.02.2021 um 16:46 schrieb Xi Ruoyao:
On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:
Hello everyone,
I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
x86_64.
When I compile M4 (chapter 6.2), I get two errors:
- gcc complains about a void function ("fault_handler") being declared
as "pure" in line 146 of m4.c
- gcc complains about the flag -Wabi which is deprecated and doesn't do
anything
(see the attached log file)
I was able to circumvent the problems by setting the environment variable
CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
these are infact bugs
in M4, so gcc is rightfully complaining.
It seems that an older gcc version had failed if that function was NOT
declared "pure"
and the M4 team has also discussed this topic in july 2020, see
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
they had also decided to make the function NOT "pure" (because
fault_handler has sideeffects
and should therefore not be pure). This was implemented by commit
74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
the declaration
is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
that is used in LFS.
I verified that LFS and LFS_TGT are set and that I'm compiling with
x86_64-lfs-linux-gnu-gcc.
Everything before M4 was built as regular user.
Those warnings should not be enabled by default.
Is your M4 tarball has the same MD5 checksum in the book? Or did you use
some
configure options not mentioned by the book?
Yes, I have compared all the MD5 sums. I followed the book very closely
and I have just compared my scripts to the book again and rebuilt again.
Everything else from chapter 5 and 6 worked fine.
The only thing I can think of that I (might) have done differently is
that I deleted the gcc-10.2.0 directory between building gcc and
libstdc++. The book doesn't explicitly say whether you should do that
and my script deletes target-directories before untaring to prevent
conflicts with previous builds (so the gcc directory is deleted because
libstdc++ is extracted to the same directory as gcc, because it comes
from the same tarball)
It should be deleted.
In the end, the function /is/ declared as pure and that /is/ logically
wrong, so it's correct of gcc to at least issue a warning. A warning is
also arguable when you pass a deprecated parameter such as -Wabi. It
seems that the warnings are turned into errors because -Werror is also
passed somewhere - I'm still looking into where that happens. But I
would argue that you should use -Werror whenever possible to avoid
unwanted results as much as possible.
It's too idealistic. Warnings like -Wmaybe-uninitialized produce false
positives by their nature. And using -Werror in a release tarball makes a bomb
which explodes if the users have a different compiler, or use some custom
CFLAGS.
In your build the configuration process somehow "--enable-gcc-warnings" is
enabled. It's intended for developers only and should not be enabled by default
in a release.
Could you attach your config.log of M4 here?
I know it's too idealistic, but I'd still prefer having it when possible.
config.log is attached. I've looked into it and also into configure.ac,
but nothing stood out to me. I'm not so familiar with the autotools - but
I guess I need to get familiar with them...
config.tar.gz
Description: application/gzip
--
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] Compiling M4 on GCC 10.2
On 2/10/21 7:16 AM, Viktor Engelmann wrote:
Am 09.02.2021 um 16:46 schrieb Xi Ruoyao:
On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:
Hello everyone,
I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
x86_64.
When I compile M4 (chapter 6.2), I get two errors:
- gcc complains about a void function ("fault_handler") being declared
as "pure" in line 146 of m4.c
- gcc complains about the flag -Wabi which is deprecated and doesn't do
anything
(see the attached log file)
I was able to circumvent the problems by setting the environment variable
CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
these are infact bugs
in M4, so gcc is rightfully complaining.
It seems that an older gcc version had failed if that function was NOT
declared "pure"
and the M4 team has also discussed this topic in july 2020, see
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
they had also decided to make the function NOT "pure" (because
fault_handler has sideeffects
and should therefore not be pure). This was implemented by commit
74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
the declaration
is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
that is used in LFS.
I verified that LFS and LFS_TGT are set and that I'm compiling with
x86_64-lfs-linux-gnu-gcc.
Everything before M4 was built as regular user.
Those warnings should not be enabled by default.
Is your M4 tarball has the same MD5 checksum in the book? Or did you use some
configure options not mentioned by the book?
Yes, I have compared all the MD5 sums. I followed the book very closely
and I have just compared my scripts to the book again and rebuilt again.
Everything else from chapter 5 and 6 worked fine.
The only thing I can think of that I (might) have done differently is
that I deleted the gcc-10.2.0 directory between building gcc and
libstdc++. The book doesn't explicitly say whether you should do that
Yes it does. Section III, Important Preliminary Material, iii. General
Compilation Instructions, second Important block, item 3e.
and my script deletes target-directories before untaring to prevent
conflicts with previous builds (so the gcc directory is deleted because
libstdc++ is extracted to the same directory as gcc, because it comes
from the same tarball)
In the end, the function /is/ declared as pure and that /is/ logically
wrong, so it's correct of gcc to at least issue a warning. A warning is
also arguable when you pass a deprecated parameter such as -Wabi. It
seems that the warnings are turned into errors because -Werror is also
passed somewhere - I'm still looking into where that happens. But I
would argue that you should use -Werror whenever possible to avoid
unwanted results as much as possible.
-Werror should never be included in released packages. If you don't use
exactly the same tools as the developer, then the odds of a problem rise
significantly. This is is especially true if the developer uses
something like gcc-10.1 and we use gcc-10.2.
-- 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] Building Python3
On 2/9/21 9:29 PM, Ken Moffat wrote: On Tue, Feb 09, 2021 at 03:24:53PM -0500, Baho Utot wrote: A note should be placed in the book about --with-ensurepip=yes. It will not build pip, setuptools and wheel if they are already installed on the system. Rebuilding python3 will not rebuild pip, setuptools and wheel as it detects that they are already installed on the system. Even if they are older than the package currently being built. ./configure --prefix=/usr \ --enable-shared \ --with-system-expat \ --with-system-ffi \ --with-ensurepip=yes Hi Scott, did you mean to post this to blfs-support rather than lfs-support ? In LFS the first build has --without-ensurepip so the second build should install it, and both will be for the same version. I don't think I have a system upgraded from 3.9 to 3.9.1 (been too busy working on systems with 3.9.1), but on the current system (3.9.1 in LFS, rebuilt in BLFS) in LFS it installed /usr/lib/python3.9/site-packages/setuptools /usr/lib/python3.9/site-packages/setuptools-49.2.1.* with /usr/lib/python3.9/site-packages/setuptools/__init__.py and various /usr/lib/python3.9/site-packages/setuptools/__pycache__/*.pyc and various other files in /usr/lib/python3.9/site-packages/setuptools/ and its subdirectories. When I rebuilt it in BLFS it seems to have overwritten one or two of those files and added a load more. and the same for pip although the only identifier for pip i nthe rebuild seems to be cpython-39 whereas in LFS chapter 8 I see pip-20.2.3.dist-info. I'm willing to believe that upgrading minor versions of python might not upgrade pip and setuptools. But I'm not a pythonista, so I have to ask: does it matter ? It does matter because if setuptools is missing you can not install or build any python modules If you do need to upgrade it (latest is now apparently v21.0.1, which dropped support for python2), according to https://pip.pypa.io/en/stable/installing/#upgrading-pip you can run python -m pip install -U pip (assuming you have python symlinked to python3, which will break seamonkey and qtwebengine out of packages in BLFS). Not if pip doesn't exist it. Since you use a package manager, doing that as a regular user will install in ~/.local/bin but all it actually does is install pip, pip3, pip3.9. I conclude that setuptools will NOT be upgraded, and I will be surprised if pip, pip3 or pip3.9 ever change. ĸen PIP will not be installed either. Your entire python installation is broken. Things like ninja and meson will fail to build. As I stated before, setuptools, pip and wheel will not be installed and everything else that you try to build will fail if it requires setup tools. you will also not be able to use the "installed python" to fix the issue. Check archlinux, They don't use ensurepip in their python building, because of this issue. You are left with a broken system. I build python without the ensurepip switch and then build setuptools, pip and wheel as modules. It is the only way you can get a functioning python installation when using a package manager. You folks don't get the problem because you do not use a package manager. -- 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] segfault building kernel (was: Compile error glibc2.33 -> binutils-2.36.1)
On 2021-02-10 10:05 -0500, Jean-Marc Pigeon wrote: > 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? Could you attach the segfaulted executable and its coredump file on segfault here? Bruce, Pierre, and I tried multiple ways to reproduce the issue but we couldn't. -- 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
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] Compiling M4 on GCC 10.2
On 2021-02-10 14:16 +0100, Viktor Engelmann wrote:
> Am 09.02.2021 um 16:46 schrieb Xi Ruoyao:
> > On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:
> > > Hello everyone,
> > >
> > > I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
> > > x86_64.
> > >
> > > When I compile M4 (chapter 6.2), I get two errors:
> > >
> > > - gcc complains about a void function ("fault_handler") being declared
> > > as "pure" in line 146 of m4.c
> > > - gcc complains about the flag -Wabi which is deprecated and doesn't do
> > > anything
> > >
> > > (see the attached log file)
> > >
> > > I was able to circumvent the problems by setting the environment variable
> > > CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
> > > these are infact bugs
> > > in M4, so gcc is rightfully complaining.
> > >
> > > It seems that an older gcc version had failed if that function was NOT
> > > declared "pure"
> > > and the M4 team has also discussed this topic in july 2020, see
> > > https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
> > > they had also decided to make the function NOT "pure" (because
> > > fault_handler has sideeffects
> > > and should therefore not be pure). This was implemented by commit
> > > 74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
> > > the declaration
> > > is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
> > > that is used in LFS.
> > >
> > > I verified that LFS and LFS_TGT are set and that I'm compiling with
> > > x86_64-lfs-linux-gnu-gcc.
> > > Everything before M4 was built as regular user.
> > Those warnings should not be enabled by default.
> >
> > Is your M4 tarball has the same MD5 checksum in the book? Or did you use
> > some
> > configure options not mentioned by the book?
>
> Yes, I have compared all the MD5 sums. I followed the book very closely
> and I have just compared my scripts to the book again and rebuilt again.
> Everything else from chapter 5 and 6 worked fine.
>
> The only thing I can think of that I (might) have done differently is
> that I deleted the gcc-10.2.0 directory between building gcc and
> libstdc++. The book doesn't explicitly say whether you should do that
> and my script deletes target-directories before untaring to prevent
> conflicts with previous builds (so the gcc directory is deleted because
> libstdc++ is extracted to the same directory as gcc, because it comes
> from the same tarball)
It should be deleted.
> In the end, the function /is/ declared as pure and that /is/ logically
> wrong, so it's correct of gcc to at least issue a warning. A warning is
> also arguable when you pass a deprecated parameter such as -Wabi. It
> seems that the warnings are turned into errors because -Werror is also
> passed somewhere - I'm still looking into where that happens. But I
> would argue that you should use -Werror whenever possible to avoid
> unwanted results as much as possible.
It's too idealistic. Warnings like -Wmaybe-uninitialized produce false
positives by their nature. And using -Werror in a release tarball makes a bomb
which explodes if the users have a different compiler, or use some custom
CFLAGS.
In your build the configuration process somehow "--enable-gcc-warnings" is
enabled. It's intended for developers only and should not be enabled by default
in a release.
Could you attach your config.log of M4 here?
--
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] Compiling M4 on GCC 10.2
Am 09.02.2021 um 16:46 schrieb Xi Ruoyao:
> On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:
>> Hello everyone,
>>
>> I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
>> x86_64.
>>
>> When I compile M4 (chapter 6.2), I get two errors:
>>
>> - gcc complains about a void function ("fault_handler") being declared
>> as "pure" in line 146 of m4.c
>> - gcc complains about the flag -Wabi which is deprecated and doesn't do
>> anything
>>
>> (see the attached log file)
>>
>> I was able to circumvent the problems by setting the environment variable
>> CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
>> these are infact bugs
>> in M4, so gcc is rightfully complaining.
>>
>> It seems that an older gcc version had failed if that function was NOT
>> declared "pure"
>> and the M4 team has also discussed this topic in july 2020, see
>> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
>> they had also decided to make the function NOT "pure" (because
>> fault_handler has sideeffects
>> and should therefore not be pure). This was implemented by commit
>> 74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
>> the declaration
>> is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
>> that is used in LFS.
>>
>> I verified that LFS and LFS_TGT are set and that I'm compiling with
>> x86_64-lfs-linux-gnu-gcc.
>> Everything before M4 was built as regular user.
> Those warnings should not be enabled by default.
>
> Is your M4 tarball has the same MD5 checksum in the book? Or did you use some
> configure options not mentioned by the book?
Yes, I have compared all the MD5 sums. I followed the book very closely
and I have just compared my scripts to the book again and rebuilt again.
Everything else from chapter 5 and 6 worked fine.
The only thing I can think of that I (might) have done differently is
that I deleted the gcc-10.2.0 directory between building gcc and
libstdc++. The book doesn't explicitly say whether you should do that
and my script deletes target-directories before untaring to prevent
conflicts with previous builds (so the gcc directory is deleted because
libstdc++ is extracted to the same directory as gcc, because it comes
from the same tarball)
In the end, the function /is/ declared as pure and that /is/ logically
wrong, so it's correct of gcc to at least issue a warning. A warning is
also arguable when you pass a deprecated parameter such as -Wabi. It
seems that the warnings are turned into errors because -Werror is also
passed somewhere - I'm still looking into where that happens. But I
would argue that you should use -Werror whenever possible to avoid
unwanted results as much as possible.
--
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, 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
