Success building seemingly native toolchain

[Richard Strand]

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

[Yann E. MORIN]

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

[martinwguy]

On 9/28/09, Yann E. MORIN <yann.morin.1998@...> 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

[Richard Strand]

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

[Oron Peled]

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: [phone]
oron@...                  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

[Richard Strand]

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

[Richard Strand]

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

[Yann E. MORIN]

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