Hi Jim, hi Bruno,

On Sat, 6 Oct 2007, Jim Meyering wrote:
Bruno Haible <[EMAIL PROTECTED]> wrote:

Martin Koeppe wrote:
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.

Adding the gnulib 'vasprintf-posix' module to bootstrap.conf should do
the trick. That's because the only 'long double' support that coreutils
requires are:
  - the elementary operations, these are inlined by gcc or come from libgcc.a,
  - asprintf(), this comes from gnulib.

The same problem with 'seq' exists on mingw and BeOS, which - like Interix -
lack 'long double' support in printf().

Thanks for the suggestion.  I'll probably do that.

Is seq segfaulting on mingw and BeOS, too?

I just tested snapshot 316 and it unfortunately doesn't work on Interix, i.e. seq is still wrong.

Interix has _ before C symbols, all the following are asm symbols. The Interix libc has __vfprintf which __printf seems to use. While _printf is a weak alias for __printf, this __printf seems to call (according to nm output of libc.a) the strong __vfprintf directly, rather than its weak alias _vfprintf. So it wouldn't even suffice to (re-)define _vfprintf.


Martin


_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to