GNU bug report logs - #16467
Diffutils 3.3 v. VMS (et al.)

Previous Next

To reply to this bug, email your comments to 16467 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Steven M. Schweda" <sms <at> antinode.info>
To: bug-diffutils <at> gnu.org
Subject: Diffutils 3.3 v. VMS (et al.)
Date: Thu, 16 Jan 2014 08:06:52 -0600 (CST)

   I normally build diffutils on a Tru64 UNIX system using the
vendor-supplied C compiler, which resembles the vendor-supplied C
compiler on VMS.  (Then I hand-edit the resulting config.h for use on
VMS.)  On Tru64, I ran into the previously reported "make check" failure
caused by the too-modern "export var=value" stuff in that "make" file. 
After getting past that problem, I was stopped by not having the exactly
correct version (1.13a) of automake.  Perhaps there's some simple
wark-around for that, but the error message I got did not lead me to it. 
Is "make check" intended only for serious developers, or should any peon
expect to be able to make it work starting from a simple source kit?

   Ignoring the lack of "make check" results, I tried to build the code
on VMS, making source changes like the now-familiar ones reported for
version 3.2 to deal with the VMS quirks, but I ran into one new problem:
The C macro HAVE_DECL_STRTOLL is still used in lib/strtoimax.c, but
seems to have disappeared from the Tru64-generated config.h.  My fault
or yours?

------------------------------------------------------------------------

   Steven M. Schweda               sms <at> antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547

Message #8 received at 16467 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Steven M. Schweda" <sms <at> antinode.info>, 16467 <at> debbugs.gnu.org
Cc: Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: [bug-diffutils] bug#16467: Diffutils 3.3 v. VMS (et al.)
Date: Thu, 16 Jan 2014 13:04:34 -0800

On 01/16/2014 06:06 AM, Steven M. Schweda wrote:

> The C macro HAVE_DECL_STRTOLL is still used in lib/strtoimax.c, but
> seems to have disappeared from the Tru64-generated config.h.  My fault
> or yours?

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.

I pushed the following patch to gnuliband am cc'ing to bug-gnulib.
Does this fix the problem for you?

---
 ChangeLog       | 11 +++++++++++
 lib/strtoimax.c | 16 ++++++++++------
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9a9f00b..ebfba06 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2014-01-16  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+    strtoimax: port to platforms lacking 'long long'
+    VMS's pre-C99 compiler lacks 'long long', so 'configure' doesn't
+    check whether strtoll is declared, which causes the C file to
+    wrongly report an error.  Problem reported by Steven M. Schweda in:
+    http://lists.gnu.org/archive/html/bug-diffutils/2014-01/msg00003.html
+    * lib/strtoimax.c (strtoull):
+    Declare only if HAVE_UNSIGNED_LONG_LONG_INT.
+    (strtoll): Declare only if HAVE_LONG_LONG_INT.
+
 2014-01-16  Daniel Albers  <daniel <at> lbe.rs>  (tiny change)
 
     relocatable-perl: fix texi syntax
diff --git a/lib/strtoimax.c b/lib/strtoimax.c
index 219ebaf..2c33d58 100644
--- a/lib/strtoimax.c
+++ b/lib/strtoimax.c
@@ -28,20 +28,24 @@
 #include "verify.h"
 
 #ifdef UNSIGNED
-# ifndef HAVE_DECL_STRTOULL
+# if HAVE_UNSIGNED_LONG_LONG_INT
+#  ifndef HAVE_DECL_STRTOULL
 "this configure-time declaration test was not run"
-# endif
-# if !HAVE_DECL_STRTOULL && HAVE_UNSIGNED_LONG_LONG_INT
+#  endif
+#  if !HAVE_DECL_STRTOULL
 unsigned long long int strtoull (char const *, char **, int);
+#  endif
 # endif
 
 #else
 
-# ifndef HAVE_DECL_STRTOLL
+# if HAVE_LONG_LONG_INT
+#  ifndef HAVE_DECL_STRTOLL
 "this configure-time declaration test was not run"
-# endif
-# if !HAVE_DECL_STRTOLL && HAVE_LONG_LONG_INT
+#  endif
+#  if !HAVE_DECL_STRTOLL
 long long int strtoll (char const *, char **, int);
+#  endif
 # endif
 #endif
 
-- 
1.8.4.2

Message #11 received at 16467 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Steven M. Schweda" <sms <at> antinode.info>, 16467 <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#16467: Diffutils 3.3 v. VMS (et al.)
Date: Thu, 16 Jan 2014 13:05:23 -0800

On 01/16/2014 06:06 AM, Steven M. Schweda wrote:
>    I normally build diffutils on a Tru64 UNIX system using the
> vendor-supplied C compiler, which resembles the vendor-supplied C
> compiler on VMS.  (Then I hand-edit the resulting config.h for use on
> VMS.)  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?

> After getting past that problem, I was stopped by not having the exactly
> correct version (1.13a) of automake.  Perhaps there's some simple
> wark-around for that, but the error message I got did not lead me to it.
> Is "make check" intended only for serious developers, or should any peon
> expect to be able to make it work starting from a simple source kit?

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).  'automake' should be required only if you're a
developer building from the git master, or if you are
editing the source code in the tarball.

Message #16 received at 16467 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 16467 <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#16467: Diffutils 3.3 v. VMS (et al.)
Date: Sat, 30 Apr 2016 19:51:23 -0700

close 16467
done

By the above, I've closed this issue.
If it's still a problem, please let us know (reply to
this thread with details) and I'll be happy to reopen it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.