Joseph S. Myers wrote:
> On Sat, 24 Oct 2009, Richard Guenther wrote:
>
>> The testsuite should run with C locale.
>
> Unfortunately it appears there are now some systems where C no longer
> implies ASCII, causing problems for predictability of output.
I was asked about this on another list
Andreas Schwab wrote:
> Dave Korn writes:
>
>> I'll check. Joseph's suggestion sounds likely: I think Cygwin just
>> switched
>> to use lots of UTF-8 internally, so I might well need to specify an encoding
>> as well. (Sorry for not being as well educated in this field as I really
>> ought to
Dave Korn writes:
> I'll check. Joseph's suggestion sounds likely: I think Cygwin just switched
> to use lots of UTF-8 internally, so I might well need to specify an encoding
> as well. (Sorry for not being as well educated in this field as I really
> ought to be by now.)
If cygwin wants to
Andrew Pinski writes:
> On Fri, Oct 23, 2009 at 4:01 PM, Dave Korn
> wrote:
>>
>> Hi everyone,
>>
>> Sorry for posting a dumb question, but it's not my strongest area: now that
>> cygwin is handling i18n and unicode and "all that stuff", I started seeing a
>> whole slew of test failures, e.g
The error is also reproduced with gcc 4.5 revision 153504
>> There is something peculiar going on, because a
>> x86_64-unknown-linux-gnu hosted compiler would not normally refer to
>> libgcc_s.so.1 at all. Even if it did, nothing would normally direct
>> the dynamic linker to look in the gcc build directory. Something is
>> wrong but I don't know what i
Ralf Corsépius wrote:
> I am observing this behavior with
> * all linux->rtems4.9/newlib (gcc-4.3.2/newlib-1.16.x) cross gccs
> * all linux->rtems4.10/newlib (gcc-4.4.2/newlib-1.17.x) cross gccs
> * linux->cygwin/newlib cross gccs (gcc 3.4.4; built from cygwin sources)
>
> I am not observing this
