bug#7228: coreutils-8.6 sort-float failure on ppc

[Jim Meyering]

Alan Curry wrote:
> Jim Meyering writes:
>> Gilles Espinasse wrote:
>> > Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
>> > ppc
>> >
>> > First a good news is that on sparc (32-bits), 8.6 test suite is now passing
>> > I didn't report yet a failure on misc/stty which was
>> > Failure was
>> > + stty -icanon
>> > stty: standard input: unable to perform all requested operations
>>
>> Is that consistently reproducible?
>> If so, you might want to investigate, but it's probably not a big deal.
>
> I've seen that error message before, and I did investigate. It was caused by
> glibc's tcsetattr()/tcgetattr() being too clever, trying to support fields
> that didn't exist in the kernel's termios struct. The kernel struct is
> arch-specific so it's not surprising that an arch-specific bug would show up
> here.
>
> I've only seen it with speed changes. stty 115200 </dev/ttyS0 makes the
> change succesfully, but complains. The kernel termios struct may or may not
> have separate speed fields for input and output, but glibc likes to pretend
> that they're both there, and somehow stty gets confused by glibc's fakery.
> strace doesn't give any clues because it shows the real kernel structures.
>
> See sysdeps/unix/sysv/linux/{speed,tc[gs]etattr}.c in glibc source for the
> full ugliness.

Thanks for the explanation.