Re: [PATCH] glibc: Refactor startfiles/headers into do_libc_backend()

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Bryan, All,

On Thursday 23 June 2011 11:20:41 Bryan Hundven wrote:
> On Wed, Jun 22, 2011 at 11:19 PM, Bryan Hundven <bryanhundven@gmail.com> wrote:
> > # HG changeset patch
> > # User Bryan Hundven <bryanhundven@gmail.com>
> > # Date 1308809915 25200
> > # Node ID 54b9dc8f9f00dce0653534c54fe2c1f6667ecc37
> > # Parent  8bb5151c5b01fb4d1ab7bc48cec563a1e6277304
> > glibc: Refactor startfiles/headers into do_libc_backend()
[--SNIP--]

Very good commit message, very inexplicative. Thank you!

[--SNIP patch--]

Nothing special to say, looks good to me. Thanks!

> I tested builds of:
> 
> mips64-octeon-linux-gnu (eglibc 2.14) (still testing sample... will
> commit when it passes more test-suite tests on my cn3120, and a kernel
> runs... at least it builds ;) )
> powerpc-e500v2-linux-gnuspe (eglibc 2.14)
> armeb-unknown-linux-gnueabi (glibc 2.13)
> i686-nptl-linux-gnu (glibc 2.13)
> 
> ..on an x86_64 host.

Good! That's a good indication that it's still working OK. Thanks for these
tests, I'll do more a bit later (as I said earlier).

Queued, thank you!

> I noticed that both the armeb and i686 builds required unwind support.
> Must be because I'm building on x86_64?
> 
> From CT_LIBC_GLIBC_FORCE_UNWIND help:
> ----------------------------------------------------------------------
> The issue seems to be related to building NPTL on old versions
> of glibc (and possibly eglibc as well) on some architectures
> (seen on s390, s390x and x86_64).
> ----------------------------------------------------------------------
> 
> Does this mean when building on these platforms, or when building
> cross tools targeted for these platforms?

Oh, bad phrasing, bad Yann... Slap cheek...

I know that it happened to me when:
 - running on x86_64
 - targetting s390{,x} and x86_64
 - building an old glibc

Maybe we could rephrase the help message a little bit, avoiding explictly
naming architectures, and just keeping the first part:

      If your toolchain fails building while building the C library
      start files, or the complete C library, with a message like:
        configure: error: forced unwind support is required
      
      then you may try setting this to 'y'. Otherwise, leave it to 'n'.

But virtually all architectures crosstool-NG can target have unwind support.
So this could maybe default to 'y'. Thoughts?

> I only noticed this issue with glibc, and not with eglibc.

OK, thanks for the confirmation. I did not observed that error with eglibc
so far, but did not even tried to reproduce it just replacing eglibc for
glibc, either.

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