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 +0000, Ken Moffat wrote:
> > > > On Tue, Feb 09, 2021 at 12:29:14AM +0000, Ken Moffat wrote:
> > > > > On Mon, Feb 08, 2021 at 03:52:35AM +0000, 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 capable Phenom II based system. Same at an older
> XEON 
> system.
> 
> --- Frans.

-- 
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

Reply via email to