From: Paul Eggert <egg...@cs.ucla-edu>
Thanks for the prompt response.
> > [...] HAVE_DECL_STRTOLL [...]
>
> I think it's a gnulib bug. We don't run into compilers lacking
> 'long long' often nowadays, so I'm not surprised the bug is there.
You need more old-junk computers in your collection.
> I pushed the following patch to gnuliband am cc'ing to bug-gnulib.
> Does this fix the problem for you?
I assume so. If HAVE_DECL_STRTOLL is back in the generated config.h
file, then that's good enough for me. Strictly speaking, it's not every
"VMS's pre-C99 compiler" which lacks "long long", but only the compilers
on VAX. On Alpha and IA64, the hardware and the compilers are newer,
and have better 64-bit support (including "long long").
> > [...] On Tru64, I ran into the previously reported "make check" failure
> > caused by the too-modern "export var=value" stuff in that "make" file.
>
> Sorry, I've forgotten which failure that was. Is it fixed
> in the git master now? Or do you have a URL for the bug?
http://lists.gnu.org/archive/html/bug-diffutils/2013-03/msg00014.html
> If you start from a tarball distribution and don't change
> it, 'make check' should not require the use of 'automake'
> (and if it does so I'd like to see how to reproduce the
> bug). [...]
Probably my fault. I may have edited too many test/Makefile.* files,
confusing the dependencies, and then failed to clean and start fresh. I
took another run at it (after getting a newer automake installed), and
had fewer problems.
There was one test failure on my Tru64 system:
[...]
PASS: test-fcntl
../build-aux/test-driver: 2615 Abort - core dumped
FAIL: test-fdopen
[...]
dbx says it's at:
4 main() ["test-fdopen.c":39, 0x120001320]
which seems to be:
ASSERT (errno == EBADF);
(dbx) p errno
24
which is EMFILE, not the expected EBADF (9). Replacing the ASSERT
macros with fprintf():
urtx# ./x1
fdopen( -1) == NULL. errno = 24: Too many open files.
fdopen( 99) == NULL. errno = 9: Bad file number.
"man fdopen" says that you'll get EBADF for an invalid "filedes"
argument, but apparently a negative value for "filedes" is just too
weird for it.
I assume that this constitutes a bug in the Tru64 C RTL, but if so,
the probability of getting it fixed these days is approximately nil.
Whether you want to do anything about it (document it, change the ASSERT
condition, supply a better fdopen(), ...) I'll leave up to you. But you
heard it here first (I assume).
Most of the VMS adaptations for version 3.3 look very like those I
made for 3.2. Those went nowhere, but if you're interested in a "diff
-ru" (or something) for 3.3, just let me know.
Thanks again for the advice.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
