Hi Eric,
On Tue, 25 Sep 2007, Eric Blake wrote:
Martin, [offlist]
I don't know if you saw this when the discussion migrated to gnulib, but
I didn't, thank you.
rather than patching error.c, I went with the option of fixing Interix's
non-POSIX strerror instead (C99 and POSIX require strerror to always
return non-NULL, even on failure). Perhaps you can give it a spin, since
I don't have an Interix environment set up?
Wait with the change! I just tested strerror() and strerror_r() on
Interix, and they already report "Unknown error: 4294967294" for e.g.
-2. Sorry.
I saw the not resolved errno only in a very special case, i.e. when
running make in a chroot, and that make calls rm which open()'s a dir,
not always, but I can reproduce it. It e.g. stops when building the
coreutils man pages with /bin/rm being the just built rm. The open()
fails in this case with errno=-1, while it should report an useful
error if it fails. But it should have no reason to fail here. Then
strerror() also fails. -1 isn't a documented errno value for open().
Everything is fine when running in the chroot without make, or with
make and outside a chroot, so strerror() isn't tested here. (Same
behaviour I got now with "sed -i" on opening the temp file within the
chroot.)
While trying to debug this I noticed the missing translation from
errno -1. But I now think it is probably a memory corruption issue or
something like that, so that strerror()/strerror_r() gets confused,
too.
Sorry for the inconvenience.
OTOH, rm from coreutils 5.97 works on Interix, while the current
6.10pre doesn't. I'm still investigating...
BTW: Interix has locales. While I build on 3.5 and never saw nor cared
about locales (but always built with libintl/libiconv), I saw on 5.2
(2003R2) suddenly translated messages from the binaries I built before
for 3.5.
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?
Martin
