Commit Message

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

Comments

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