This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |