Re: [RFC PATCH] allow arbitrary Linux kernel versions

[Johannes Stezenbach <js at sig21 dot net>]

Hi Yann,

On Wed, Sep 26, 2012 at 07:27:04PM +0200, Yann E. MORIN wrote:
> On Wednesday 26 September 2012 15:07:54 Johannes Stezenbach wrote:
> > Allow the user to specify a specific Linux kernel version.
> > In contrast to KERNEL_LINUX_CUSTOM crosstool
> > will automatically download the tarball (provided the
> > version number entered by the user is valid).
> > Using this also stops crosstool from downloading
> > the latest-greatest kernel after every crosstool update.
> 
> I do not like for at least one reason: if we do it for the kernel, why not
> do it for all the other components as well? And in this case, we should
> have a way to commonalise the method (config.in and scripts).
> 
> Also, I do not like to offer this option, because there are often people
> that want to use a very old kernel (eg. in the 2.4 series, of pre 2.6.18),
> which definitely will *not* work, and I want to avoid this situation.
> 
> In contrast to other components, for which there are no hard reason not to
> use old versions, too old a kernel is a sure way to break the build.
> 
> OTOH, it is already possible to use any version, via the "custom tarball or
> directory" option. Sure, it requires that the tarball be already downloaded,
> but I believe that to be a minor issue.

Exactly, the new option doesn't add a new way to break
the build, it just make it easier :-)

> If the use-case is to use newer kernel versions, then it is also time to
> upgrade to a newer crosstool-NG, too.
> 
> So, I am against this change. Unless you have very, *very strong* counter-
> arguments, of course. ;-)

I'll tell you the full story behind that patch:

I have a working ARM toolchain build with uClibc.  Now I was asked
to build the same thing with (e)glibc.  But the eglibc didn't build,
because the eglibc-1.16 patch didn't apply.  I think it is the fault
of the eglibc people because they don't do releases, and ct-ng
just fetches the head of the eglibc_1_16 branch.  Maybe ct-ng
should fetch a specific, tested, svn revision, I don't know.
At least ct-ng saves a tarball of the downloaded eglibc so the
build is repeatable.

Seeing there were some eglibc patches merged recently I updated
ct-ng to hg tip.  And thus I get new versions of linaro gcc
and the linux kernel shoved down my throat.  In this case I'm
OK with the linaro update, but I didn't like updating
from linux-3.4.9 to 3.4.11 if it takes another full linux tarball
download.  Both my patience and my disk space are limited.
I know that 3.4.11 could potentially have important fixes
but atm I don't care :-)

I have no hard feelings if you don't like the patch, I can
easily fixup ct-ng locally to use the versions I like.
I don't like the "custom tarball" option since I'm not using
a customized linux version.  I want ct-ng config to record
the used version and download it if needed.

BTW, with the linaro gcc update, ct-ng forgot
that I selected linaro gcc and switched to "gcc from svn".
Ideally ct-ng would remember the major version and only
update the minor, e.g. from gcc-linaro-4.6-2012.08
to gcc-linaro-4.6-2012.09.

BTW2, my builds don't work today but I'm not yet sure what
the problem is.  It fails in "Installing pass-1 core C compiler"
stage:

[ALL  ]    x86_64-build_unknown-linux-gnu-gcc   -pipe -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H  -o lto1                lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o main.o  libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lcloog -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lppl_c -lppl  -lgmpxx -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lpwl -L../zlib -lz ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lpwl
[ALL  ]    /usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi
[ALL  ]    Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om
[ERROR]    collect2: error: ld returned 1 exit status
[ERROR]    make[2]: *** [lto1] Error 1

This also happens with the known good gcc-linaro-4.6-2012.08
so it's either an issue of ct-ng or Debian unstable build host.


Thanks
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq