| Message ID | 20120926130754.GA26711@sig21.net |
|---|---|
| State | Rejected |
| Headers | show |
Johannes, All, 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. 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. ;-) Regards, Yann E. MORIN.
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
Johannes, All, On Wednesday 26 September 2012 22:18:22 Johannes Stezenbach wrote: > On Wed, Sep 26, 2012 at 07:27:04PM +0200, Yann E. MORIN wrote: [--SNIP--] > > 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: Ah! I like stories! :-) > 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. Well, you can tell ct-ng what revision to use: C library ---> (HEAD) Revision to use Yes, the default is 'HEAD', but if you specify a revision, that's what's gona be used. Yes, patches in the repository apply to a specific revision. I am not too fond of this situation, but the fault is really on the eglibc folks, that do not do releases. Not sure if the default in crosstool-NG should be a specific revision either. I'm afraid that might turn into a maintenance nightmare, and I do not have the back solid enough to handle that. > 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. OK, I see. The crosstool-NG's .config were never meant to be portable between versions. No, that's stated nowhere; nor is the opposite, either. However, see below, there might be something to mitigate this issue. > I have no hard feelings if you don't like the patch, Oh, the patch is technically correct. No problem with that at all. It's just that the feature is not appealing to me (as the maintainer, I also need to ensure that I can live with that in the future, and I doubt that would be doable for the reasons I exposed). > 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. So, from what I understand from your story, the problem is not: I want to use a specific version of the kernel. But: I want to use the same kernel version I used in a previous ct-ng version. That's not really doable, because the versions listed in ct-ng *will* change with time, and it's not really doable to maintain all those versions (especially the kernel, eg. for the 2.6.27 series which is now toping at 2.6.27.62! That's to date 478 versions since 2.6.18 was released). But see below, for the gcc linaro stuff... > BTW, with the linaro gcc update, ct-ng forgot > that I selected linaro gcc and switched to "gcc from svn". Same reason as above, but more unfortunate. I've been bitten by this, too. I'm thinking about it... > 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. OK, that's a sane idea. Currently, the config does (roughly!): config GCC_V_linaro_4_6_2010_09 bool "linaro-4.6-2012.09" config GCC_VERSION string default "linaro-4.6-2012.09" if GCC_V_linaro_4_6_2010_09 This could be changed to: config GCC_V_linaro_4_6 bool "linaro-4.6 (2012.09)" config GCC_VERSION string default "linaro-4.6-2012.09" if GCC_V_linaro_4_6 Thus, the new config would "maintain" the linaro 'major' selection, and only upgrade the 'minor' version. Is that the behavior you are suggesting? And maybe we could use a similar scheme for other components, such as the Linux kernel: - for the latest major release (eg. gcc-4.7 today), keep all sub-versions - for previous major releases (eg. gcc-4.6, 4.5...), keep only the "major" version ID in the config, and update the minor version only in the "string" option, thus allowing to more easily forward a .config to a newer ct-ng version. Could that be a correct answer to your issue? What would be missing in this proposal to fully address your problem? > 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: [--SNIP--] > [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 Fixed just pushed earlier today. Thank you for the explanations! I think we can come to an arrangement you and I can not refuse! ;-) [Read that with the voice Marlon Brando, in The Godfather. Hehe!] Regards, Yann E. MORIN.
On Wed, Sep 26, 2012 at 2:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > Johannes, All, > > On Wednesday 26 September 2012 22:18:22 Johannes Stezenbach wrote: >> On Wed, Sep 26, 2012 at 07:27:04PM +0200, Yann E. MORIN wrote: > [--SNIP--] >> > 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: > > Ah! I like stories! :-) > >> 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. > > Well, you can tell ct-ng what revision to use: > > C library ---> > (HEAD) Revision to use > > Yes, the default is 'HEAD', but if you specify a revision, that's > what's gona be used. > > Yes, patches in the repository apply to a specific revision. I am > not too fond of this situation, but the fault is really on the eglibc > folks, that do not do releases. > > Not sure if the default in crosstool-NG should be a specific revision > either. I'm afraid that might turn into a maintenance nightmare, and > I do not have the back solid enough to handle that. > >> 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. > > OK, I see. The crosstool-NG's .config were never meant to be portable > between versions. No, that's stated nowhere; nor is the opposite, either. > > However, see below, there might be something to mitigate this issue. > >> I have no hard feelings if you don't like the patch, > > Oh, the patch is technically correct. No problem with that at all. It's > just that the feature is not appealing to me (as the maintainer, I also > need to ensure that I can live with that in the future, and I doubt that > would be doable for the reasons I exposed). > >> 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. > > So, from what I understand from your story, the problem is not: > I want to use a specific version of the kernel. > But: > I want to use the same kernel version I used in a previous > ct-ng version. > > That's not really doable, because the versions listed in ct-ng *will* > change with time, and it's not really doable to maintain all those > versions (especially the kernel, eg. for the 2.6.27 series which is > now toping at 2.6.27.62! That's to date 478 versions since 2.6.18 was > released). There is something that can be done about this. I have some WIP changes to crosstool-ng to unify the way we get files and source code (from tarballs, git, svn, cvs, etc...). Once this is done, it will be easier to add getting the kernel from git at a specific repository/branch/commit/tag. (much like my recent change to get gcc from svn) This might be the right way to deal with that issue. Of course if any patches are needed, they would have to be local patches and crosstool-ng would not support them. > But see below, for the gcc linaro stuff... > >> BTW, with the linaro gcc update, ct-ng forgot >> that I selected linaro gcc and switched to "gcc from svn". > > Same reason as above, but more unfortunate. I've been bitten by this, too. > I'm thinking about it... > >> 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. > > OK, that's a sane idea. It might be the same for linaro, as they do have a release git tree. > Currently, the config does (roughly!): > > config GCC_V_linaro_4_6_2010_09 > bool "linaro-4.6-2012.09" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6_2010_09 > > This could be changed to: > > config GCC_V_linaro_4_6 > bool "linaro-4.6 (2012.09)" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6 > > Thus, the new config would "maintain" the linaro 'major' selection, and > only upgrade the 'minor' version. Is that the behavior you are suggesting? > > And maybe we could use a similar scheme for other components, such as the > Linux kernel: > > - for the latest major release (eg. gcc-4.7 today), keep all sub-versions > - for previous major releases (eg. gcc-4.6, 4.5...), keep only the "major" > version ID in the config, and update the minor version only in the > "string" option, thus allowing to more easily forward a .config to a > newer ct-ng version. > > Could that be a correct answer to your issue? > What would be missing in this proposal to fully address your problem? > >> 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: > [--SNIP--] >> [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 > > Fixed just pushed earlier today. > > > Thank you for the explanations! > > I think we can come to an arrangement you and I can not refuse! ;-) > [Read that with the voice Marlon Brando, in The Godfather. Hehe!] > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' > > -- > For unsubscribe information see http://sourceware.org/lists.html#faq > -Bryan -- For unsubscribe information see http://sourceware.org/lists.html#faq
"Yann E. MORIN" <yann.morin.1998@free.fr> writes: >> 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. > > OK, that's a sane idea. > > Currently, the config does (roughly!): > > config GCC_V_linaro_4_6_2010_09 > bool "linaro-4.6-2012.09" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6_2010_09 > > This could be changed to: > > config GCC_V_linaro_4_6 > bool "linaro-4.6 (2012.09)" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6 > > Thus, the new config would "maintain" the linaro 'major' selection, and > only upgrade the 'minor' version. Is that the behavior you are suggesting? I for one would like to see that minor change in behavior :-) > And maybe we could use a similar scheme for other components, such as the > Linux kernel: > > - for the latest major release (eg. gcc-4.7 today), keep all sub-versions > - for previous major releases (eg. gcc-4.6, 4.5...), keep only the "major" > version ID in the config, and update the minor version only in the > "string" option, thus allowing to more easily forward a .config to a > newer ct-ng version. > > Could that be a correct answer to your issue? +1 :-) It would slightly easy upgrading of ct-NG in OE-lite. /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
Hi Yann, On Wed, Sep 26, 2012 at 11:23:30PM +0200, Yann E. MORIN wrote: > On Wednesday 26 September 2012 22:18:22 Johannes Stezenbach wrote: > > 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. > > Well, you can tell ct-ng what revision to use: > > C library ---> > (HEAD) Revision to use > > Yes, the default is 'HEAD', but if you specify a revision, that's > what's gona be used. > > Yes, patches in the repository apply to a specific revision. I am > not too fond of this situation, but the fault is really on the eglibc > folks, that do not do releases. > > Not sure if the default in crosstool-NG should be a specific revision > either. I'm afraid that might turn into a maintenance nightmare, and > I do not have the back solid enough to handle that. OK, I didn't notice CT_EGLIBC_REVISION, but if I had I wouldn't really know what to put in there. Maybe a good guess would be the date of the ct-ng release. > OK, I see. The crosstool-NG's .config were never meant to be portable > between versions. No, that's stated nowhere; nor is the opposite, either. Well, I used "ct-ng oldconfig" and hoped it work ;-) > > 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. > > OK, that's a sane idea. > > Currently, the config does (roughly!): > > config GCC_V_linaro_4_6_2010_09 > bool "linaro-4.6-2012.09" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6_2010_09 > > This could be changed to: > > config GCC_V_linaro_4_6 > bool "linaro-4.6 (2012.09)" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6 > > Thus, the new config would "maintain" the linaro 'major' selection, and > only upgrade the 'minor' version. Is that the behavior you are suggesting? Yes, sounds good. > And maybe we could use a similar scheme for other components, such as the > Linux kernel: > > - for the latest major release (eg. gcc-4.7 today), keep all sub-versions > - for previous major releases (eg. gcc-4.6, 4.5...), keep only the "major" > version ID in the config, and update the minor version only in the > "string" option, thus allowing to more easily forward a .config to a > newer ct-ng version. > > Could that be a correct answer to your issue? > What would be missing in this proposal to fully address your problem? I think it would be much better than what we have now. > > 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: > [--SNIP--] > > [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 > > Fixed just pushed earlier today. Ah, the LIBRARY_PATH thing. The patch which tried to unset it should have use "unset" instead of setting it to empty. Thank you! Johannes -- For unsubscribe information see http://sourceware.org/lists.html#faq
diff -r f36c207348ef config/kernel/linux.in --- a/config/kernel/linux.in Thu Sep 20 11:20:16 2012 +0800 +++ b/config/kernel/linux.in Wed Sep 26 14:55:56 2012 +0200 @@ -135,12 +135,26 @@ It is now maintained by Greg Kroah-Hartman, see this mailing list entry: http://marc.info/?l=linux-kernel&m=129133701916793&w=4 +config KERNEL_LINUX_CUSTOM_VERSION + bool + prompt "custom Linux version" + help + Use a specific version not metioned in the list above. + config KERNEL_LINUX_CUSTOM bool prompt "custom tarball or directory" help Use a local tarball or local kernel directory of a complete kernel source tree. +endchoice + +config KERNEL_LINUX_CUSTOM_VERSION_NUMBER + string "" + prompt "custom Linux version number" + help + Enter the specific Linux kernel version to use, e.g. "3.4.9". + config KERNEL_LINUX_CUSTOM_LOCATION string prompt "Path to custom source, tarball or directory" @@ -149,8 +163,6 @@ Enter here the path to the tarball of your full kernel tree or kernel directory -endchoice - config KERNEL_VERSION string # Don't remove next line @@ -173,6 +185,7 @@ default "2.6.32.59" if KERNEL_V_2_6_32_59 default "2.6.31.14" if KERNEL_V_2_6_31_14 default "2.6.27.62" if KERNEL_V_2_6_27_62 + default KERNEL_LINUX_CUSTOM_VERSION_NUMBER if KERNEL_LINUX_CUSTOM_VERSION default "custom" if KERNEL_LINUX_CUSTOM endif # ! KERNEL_LINUX_USE_CUSTOM_HEADERS
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. Signed-off-by: Johannes Stezenbach <js@sig21.net> -- For unsubscribe information see http://sourceware.org/lists.html#faq