From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27652 invoked by alias); 26 Sep 2012 20:18:46 -0000 Received: (qmail 27634 invoked by uid 22791); 26 Sep 2012 20:18:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_PX,TW_SV X-Spam-Check-By: sourceware.org Received: from bar.sig21.net (HELO bar.sig21.net) (80.81.252.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Sep 2012 20:18:30 +0000 Received: from p5ddc55e7.dip.t-dialin.net ([93.220.85.231] helo=abc.local) by bar.sig21.net with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1TGy3r-0004lx-DF; Wed, 26 Sep 2012 22:18:28 +0200 Received: from js by abc.local with local (Exim 4.80) (envelope-from ) id 1TGy3q-0005Z6-4M; Wed, 26 Sep 2012 22:18:22 +0200 Date: Wed, 26 Sep 2012 20:18:00 -0000 From: Johannes Stezenbach To: "Yann E. MORIN" Cc: crossgcc@sourceware.org Subject: Re: [RFC PATCH] allow arbitrary Linux kernel versions Message-ID: <20120926201822.GA21265@sig21.net> References: <20120926130754.GA26711@sig21.net> <201209261927.04071.yann.morin.1998@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <201209261927.04071.yann.morin.1998@free.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-21-Score: -2.9 (--) X-Spam-21-Report: No, score=-2.9 required=8.0 tests=ALL_TRUSTED=-1,BAYES_00=-1.9 autolearn=ham X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00128.txt.bz2 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > OTOH, it is already possible to use any version, via the "custom tarball = or > directory" option. Sure, it requires that the tarball be already download= ed, > 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. >=20 > 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 -DCRO= SS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-proto= types -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-l= ong -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 ../lib= decnumber/libdecnumber.a -L/tmp/build/.build/arm-unknown-linux-gnueabi/buil= dtools/lib -lcloog -L/tmp/build/.build/arm-unknown-linux-gnueabi/buildtools= /lib -lppl_c -lppl -lgmpxx -L/tmp/build/.build/arm-unknown-linux-gnueabi/b= uildtools/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/t= mp/build/.build/arm-unknown-linux-gnueabi/buildtools/lib -lpwl -L../zlib -l= z ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumbe= r.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