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]

Re: [RFC PATCH] allow arbitrary Linux kernel versions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]