Linux-188.8.131.52 build failure
zarniwhoop73 at googlemail.com
Wed Dec 2 16:25:14 PST 2009
2009/12/2 Bruce Dubbs <bruce.dubbs at gmail.com>:
> Mykal Funk wrote:
>> I am trying to upgrade an LFS 5 system so that I can build an updated
>> LFS 6.5 system. However the compile fails with this output.
>> MODPOST vmlinux.o
>> WARNING: modpost: Found 5 section mismatch(es).
>> To see full details build you kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> GEN .version
>> CHK include/linux/compile.h
>> dnsdomainname: Host name lookup failure
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD int/built-in.o
>> LD .tmp_vmlinux1
>> ld:arch/x86/kernel/vmlinux.lds:473: parse error
>> make: *** [.tmp_vmlinux1] Error 1
>> Current kernel is linux-2.4.22-openmosix-2, if that helps. I've googled
>> around and haven't found anything. I can't get this kernel to compile
>> and I'm not sure why.
In this case, it appears your binutils is too old.
> It's been a long time since I head of anyone still using 2.4.x.
> When LFS first transitioned to the 2.6.x kernels, we didn't have a way
> to build it other than to load a commercial distro and build from there.
> Of course someone did the first build to 2.6, but that was back in
> 2003. We don't have a build path for 2.4.x->2.6.x and we now specify at
> least 2.6.18.
Much as I hesitate to disagree, many people built 2.6 kernels from
then-recent LFS builds. AFAIR the big issue was installing module
init tools with the correct workarounds so that 2.4 kernels could still
But since then, everything has moved on and I'd be surprised if the
recent versions of module-init-tools still support the workaround (and
anyway I've forgotten the details of it).. So Bruce's suggestion to use
a distro (or the last LFS Live CD - plus a current version of the book
and the packages to go with that) is the most efficient use of your
The alternative is to build a toolchain for the kernel (in /usr/local
or ~/ or /opt/something - you only need binutils and gcc's (kernel
only needs C, but otehr things in chapter 5 will need C++ so best
to build both), build the version of the 2.6 kernel you intend to use (but
without modules), and then see if that toolchain is good enough.
Unfortunately, picking suitable old versions is guesswork - I thought
there were tests in the kernel build system, particularly for gcc, but
all I can find from a quick look is Documentation/Changes which still
claims gcc-3.2 and binutils-2.12 are adequate - on x86 I'm certain
they are unlikely to be adequate.
The slightly longer-winded version is to build several versions of
gcc and binutils, using each to build a newer version. As always,
the version of binutils needs to be suitable for the version of gcc
but these things are never documented. Looking back to my old
notes, I guess the following versions might be worth exploring
e.g. first one in /opt/tools1, second in /opt/tools2 - during
toolchain builds set PATH to /opt/tools3:/opt/tools2:/opt/tools1:
and then the normal PATH after that.
binutils-2.14 and gcc-3.3.5 (based loosely on 5.1)
binutils-2.16.1 and gcc-4.0.2
binutils-2.17 and gcc-4.1.2 - I would very much hope that is recent
enough to build a current system (and particularly a current kernel).
If you want to try this, you could even see if the more recent
toolchain will build on your current system. Unfortunately, you
will be totally on your own for this, there are no guarantees and
it's even possibly that the old glibc might cause problems during
the build or the testing. It's also possible that something else
entirely is causing your version of ld to complain. The vmlinux.lds
file is generated from your kernel .config so we've no idea what is
on the line in question, and in any case I doubt there is anyone
here who is familiar enough with the toolchain to diagnose the
exact problem / required package version. :(
In general, once you build LFS you are responsible for updating
it, and rebuilding it in due course. I think you've left this one a bit
After tragedy, and farce, "OMG poneys!"
More information about the lfs-support