Hi Jim,
On Wed, 3 Oct 2007, Jim Meyering wrote:
And yes, I'll of course try a new coreutils/gnulib version (but I
think in this case I shouldn't yet). Are there any coreutils snapshot
.tar.gz available?
Yes. I made a new snapshot just a few hours ago, too:
http://meyering.net/cu/coreutils-6.9-ss.tar.gz
http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig
I now built the newer snapshot from 2-Oct-2007 and ran the tests. Long
Thanks.
The three that failed with 'Segmentation fault' look like
good candidates to investigate first. Can you debug those?
the second and third (they occur when seq is run) are easy to explain,
but probably difficult to fix...
The Interix libc is built with MSVC. MSVC has no long double data
type. Ok, it understands "long double", but always maps that to 64-bit
double. So libc's printf(), when it sees "%Lg", expects 64-bit double.
But Interix also has gcc. gcc OTOH has 80 bit long double (stored are
12 bytes). When I build seq with gcc, for the "%Lg" arg 12 bytes are
reserved. This will crash then.
I don't know how to fix that... Is there a way to force seq to only
use double, no long double? OTOH I plan to eventually port glibc
to Interix some (very?) future day, as I also noticed several other
problems with Interix's libc.
Are there other long double printf usages in coreutils which might be
broken on Interix, too?
The first 'Segmentation fault' with dd doesn't occur when I run just
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync < dd-in > dd-out
dd-out looks fine there. So I don't currently know how to reproduce
it...
Martin
