public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@sig21.net>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: crossgcc@sourceware.org
Subject: Re: [RFC PATCH] allow arbitrary Linux kernel versions
Date: Thu, 27 Sep 2012 10:14:00 -0000	[thread overview]
Message-ID: <20120927101406.GB32423@sig21.net> (raw)
In-Reply-To: <201209262323.30715.yann.morin.1998@free.fr>

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

      parent reply	other threads:[~2012-09-27 10:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-26 13:08 Johannes Stezenbach
2012-09-26 17:27 ` Yann E. MORIN
2012-09-26 20:18   ` Johannes Stezenbach
2012-09-26 21:23     ` Yann E. MORIN
2012-09-26 22:34       ` Bryan Hundven
2012-09-27  4:43       ` Esben Haabendal
2012-09-27 10:14       ` Johannes Stezenbach [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120927101406.GB32423@sig21.net \
    --to=js@sig21.net \
    --cc=crossgcc@sourceware.org \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).