[RFC PATCH] allow arbitrary Linux kernel versions

Yann E. MORIN yann.morin.1998@free.fr
Wed Sep 26 21:23:00 GMT 2012


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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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



More information about the crossgcc mailing list