public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* Success building seemingly native toolchain
@ 2009-09-15 16:58 Richard Strand
  2009-09-28 20:09 ` Yann E. MORIN
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Strand @ 2009-09-15 16:58 UTC (permalink / raw)
  To: yann.morin.1998; +Cc: crossgcc

Hi,

I had a problem where crosstool-ng would break when it was building NPTL 
when using glibc 2.7 and above. As I am using i686 to build i486 I 
suspect this was the "seemingly native toolchains do not build" bug. I 
have now managed to successfully get this to build by setting 
CT_TARGET_CFLAGS="-O2".

Is this a known workaround for the problem (I couldn't find anything on 
it), and does this work for everyone else?

Regards,

Richard Strand

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-15 16:58 Success building seemingly native toolchain Richard Strand
@ 2009-09-28 20:09 ` Yann E. MORIN
  2009-09-29 16:29   ` Martin Guy
                     ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Yann E. MORIN @ 2009-09-28 20:09 UTC (permalink / raw)
  To: Richard Strand; +Cc: crossgcc

Hello Richard!

Sorry for the long delay...

On Tuesday 15 September 2009 18:58:24 Richard Strand wrote:
> I had a problem where crosstool-ng would break when it was building NPTL 
> when using glibc 2.7 and above. As I am using i686 to build i486 I 
> suspect this was the "seemingly native toolchains do not build" bug.

Yes, you hit it.

> I have now managed to successfully get this to build by setting 
> CT_TARGET_CFLAGS="-O2".

Ah! So far, CT_TARGET_CFLAGS is used only to build the C library (except
uClibc) and gcc.

glibc (and eglibc) are known to mis-compile (or refuse to compile at
all) if -O is not specified in the CFLAGS. That's why it is currently
hard-coded in the scripts. It is not said in the gcc manual if -O
options are cumulative or if any -O option overrides any preceding
option; in the build scripts, -O is specified after CT_TARGET_CFLAGS.

I don't know about gcc, but building the final compiler is the only
place that uses CT_TARGET_CFLAGS. I can't say how this is used by the
gcc makefiles.

> Is this a known workaround for the problem (I couldn't find anything on 
> it), and does this work for everyone else?

This is not a known workaround. But it might be as good as any thing
else. Was your toolchain fully working? If so, then we might consider
changing the -O into a -O2.

Thanks for the info!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-28 20:09 ` Yann E. MORIN
@ 2009-09-29 16:29   ` Martin Guy
  2009-09-29 16:48   ` Richard Strand
  2009-10-02 18:30   ` Richard Strand
  2 siblings, 0 replies; 8+ messages in thread
From: Martin Guy @ 2009-09-29 16:29 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: Richard Strand, crossgcc

On 9/28/09, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
> It is not said in the gcc manual if -O
> options are cumulative or if any -O option overrides any preceding
>  option

I think it does somewhere deep in "man gcc", but anyway it's the
second of the two, and -O is short for -O1

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-28 20:09 ` Yann E. MORIN
  2009-09-29 16:29   ` Martin Guy
@ 2009-09-29 16:48   ` Richard Strand
  2009-09-29 23:07     ` Oron Peled
  2009-10-02 18:30   ` Richard Strand
  2 siblings, 1 reply; 8+ messages in thread
From: Richard Strand @ 2009-09-29 16:48 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

Yann E. MORIN wrote:
> Hello Richard!
>
> Sorry for the long delay...
>   
No problem!

> On Tuesday 15 September 2009 18:58:24 Richard Strand wrote:
>   
>> I had a problem where crosstool-ng would break when it was building NPTL
>> when using glibc 2.7 and above. As I am using i686 to build i486 I
>> suspect this was the "seemingly native toolchains do not build" bug.
>>     
>
> Yes, you hit it.
>
>   
>> I have now managed to successfully get this to build by setting
>> CT_TARGET_CFLAGS="-O2".
>>     
>
> Ah! So far, CT_TARGET_CFLAGS is used only to build the C library (except
> uClibc) and gcc.
>
> glibc (and eglibc) are known to mis-compile (or refuse to compile at
> all) if -O is not specified in the CFLAGS. That's why it is currently
> hard-coded in the scripts. It is not said in the gcc manual if -O
> options are cumulative or if any -O option overrides any preceding
> option; in the build scripts, -O is specified after CT_TARGET_CFLAGS.
>
> I don't know about gcc, but building the final compiler is the only
> place that uses CT_TARGET_CFLAGS. I can't say how this is used by the
> gcc makefiles.
>
>   
>> Is this a known workaround for the problem (I couldn't find anything on
>> it), and does this work for everyone else?
>>     
>
> This is not a known workaround. But it might be as good as any thing
> else. Was your toolchain fully working? If so, then we might consider
> changing the -O into a -O2.
>   

The toolchain is working perfectly for me and I've not run into any 
problems yet. Changing to -O2 sounds like a good idea as long as it 
doesn't break builds for any other architectures.

Regards,

--Richard Strand


--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-29 16:48   ` Richard Strand
@ 2009-09-29 23:07     ` Oron Peled
  2009-09-30 12:04       ` Richard Strand
  0 siblings, 1 reply; 8+ messages in thread
From: Oron Peled @ 2009-09-29 23:07 UTC (permalink / raw)
  To: crossgcc; +Cc: Richard Strand, Yann E. MORIN

On Tuesday, 29 בSeptember 2009 18:48:23 Richard Strand wrote:
> The toolchain is working perfectly for me and I've not run into any 
> problems yet. Changing to -O2 sounds like a good idea as long as it 
> doesn't break builds for any other architectures.

I'm not sure if it's related, but AFAIR g++ only consider inline
of C++ methods with -O2 or more (maybe some of the inline methods
are crucial for g++ or glibc itself).

-- 
Oron Peled                                 Voice: +972-4-8228492
oron@actcom.co.il                  http://users.actcom.co.il/~oron
"A standard for copy protection is as premature as a standard for 
teleportation."
                                --- Noted computer security expert and
                                    Princeton University Professor
                                    Edward Felten.

--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-29 23:07     ` Oron Peled
@ 2009-09-30 12:04       ` Richard Strand
  0 siblings, 0 replies; 8+ messages in thread
From: Richard Strand @ 2009-09-30 12:04 UTC (permalink / raw)
  To: Oron Peled; +Cc: crossgcc, Yann E. MORIN

Oron Peled wrote:
> On Tuesday, 29 בSeptember 2009 18:48:23 Richard Strand wrote:
>   
>> The toolchain is working perfectly for me and I've not run into any
>> problems yet. Changing to -O2 sounds like a good idea as long as it
>> doesn't break builds for any other architectures.
>>     
>
> I'm not sure if it's related, but AFAIR g++ only consider inline
> of C++ methods with -O2 or more (maybe some of the inline methods
> are crucial for g++ or glibc itself).
>   
It seems that if no CFLAGS are specified when compiling glibc then it 
automatically uses -O2. Hopefully this means that -O2 is safe, and is 
probably preferable to using -O.

Regards,

--Richard Strand


--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-09-28 20:09 ` Yann E. MORIN
  2009-09-29 16:29   ` Martin Guy
  2009-09-29 16:48   ` Richard Strand
@ 2009-10-02 18:30   ` Richard Strand
  2009-10-03 16:25     ` Yann E. MORIN
  2 siblings, 1 reply; 8+ messages in thread
From: Richard Strand @ 2009-10-02 18:30 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc

Yann E. MORIN wrote:
>> I have now managed to successfully get this to build by setting
>> CT_TARGET_CFLAGS="-O2".
>>     
>
> Ah! So far, CT_TARGET_CFLAGS is used only to build the C library (except
> uClibc) and gcc.
>
> glibc (and eglibc) are known to mis-compile (or refuse to compile at
> all) if -O is not specified in the CFLAGS. That's why it is currently
> hard-coded in the scripts. It is not said in the gcc manual if -O
> options are cumulative or if any -O option overrides any preceding
> option; in the build scripts, -O is specified after CT_TARGET_CFLAGS.
>
> I don't know about gcc, but building the final compiler is the only
> place that uses CT_TARGET_CFLAGS. I can't say how this is used by the
> gcc makefiles.
>
>   
>> Is this a known workaround for the problem (I couldn't find anything on
>> it), and does this work for everyone else?
>>     
>
> This is not a known workaround. But it might be as good as any thing
> else. Was your toolchain fully working? If so, then we might consider
> changing the -O into a -O2.
>   

Setting -O2 fixes the build for eglibc as well which also seems to fail 
with -O (tested version 2.8).

Regards,

Richard Strand


--
For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Success building seemingly native toolchain
  2009-10-02 18:30   ` Richard Strand
@ 2009-10-03 16:25     ` Yann E. MORIN
  0 siblings, 0 replies; 8+ messages in thread
From: Yann E. MORIN @ 2009-10-03 16:25 UTC (permalink / raw)
  To: Richard Strand; +Cc: crossgcc

Richard,
All,

On Friday 02 October 2009 20:30:08 Richard Strand wrote:
> Setting -O2 fixes the build for eglibc as well which also seems to fail 
> with -O (tested version 2.8).

Thank you for the report!
I've changed the code to using a hard-coded -O2, now.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2009-10-03 16:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-15 16:58 Success building seemingly native toolchain Richard Strand
2009-09-28 20:09 ` Yann E. MORIN
2009-09-29 16:29   ` Martin Guy
2009-09-29 16:48   ` Richard Strand
2009-09-29 23:07     ` Oron Peled
2009-09-30 12:04       ` Richard Strand
2009-10-02 18:30   ` Richard Strand
2009-10-03 16:25     ` Yann E. MORIN

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