[PATCH] glibc: Refactor startfiles/headers into do_libc_backend()
Yann E. MORIN
yann.morin.1998@anciens.enib.fr
Thu Jun 23 23:34:00 GMT 2011
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
More information about the crossgcc
mailing list