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