Discussion:
Fix for lib/same-inode.h for VMS
(too old to reply)
John E. Malmberg
2017-06-03 03:47:02 UTC
Permalink
Raw Message
VMS 8.2 and later provide a 64 bit ino_t type when _USE_STD_STAT is
defined on the command line.

This patch makes the fallback to the old VMS behavior for only VMS 8.1
and earlier.

This patch also adds an assert to require that VMS programmers have the
_USE_STD_STAT defined for VMS 8.2+.

Regards,
-John
Paul Eggert
2017-06-04 21:32:11 UTC
Permalink
Raw Message
VMS 8.2 and later provide a 64 bit ino_t type when _USE_STD_STAT is defined on
the command line.
Thanks for the heads-up. I see that 8.2 came out in 2005; I guess news travels
slowly from the VMS world to the Gnulib world.

Instead of a pragma for checking, how about if we define _USE_STD_STAT all the
time? That makes sense for Gnulib-using applications. Also, I don't see why
__DECC is relevant here; shouldn't the decision be compiler-independent? Anyway,
for now I installed the attached patch.
John E. Malmberg
2017-06-05 03:04:36 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by John E. Malmberg
VMS 8.2 and later provide a 64 bit ino_t type when _USE_STD_STAT is
defined on the command line.
Thanks for the heads-up. I see that 8.2 came out in 2005; I guess news
travels slowly from the VMS world to the Gnulib world.
The Sourceforge GNV project has a backlog of things to get into shape
for submission or set up as a supplemental library. We are trying to
keep close to current, but are not yet able to build "master" branches.

GNV is now:

Bash 4.3.46 bzip2 1.0-6 coreutils 8.26 diffutils 3.5
gawk 4.1-4 grep 2.25 make-3.78.1-forked ncompress 4.2.4
sed 4.2-2

gzip 1.7 is currently in test state.
tar 1.29 port just starting.
xz port just starting.
Post by Paul Eggert
Instead of a pragma for checking, how about if we define _USE_STD_STAT
all the time? That makes sense for Gnulib-using applications. Also, I
don't see why __DECC is relevant here; shouldn't the decision be
compiler-independent? Anyway, for now I installed the attached patch.
I do not know if the pragma for the assert would be valid for anything
other than __DECC compiler which was why the check was present. The
assert and related comments were to make it clear to other VMS
programmers that it was intentional that _USE_STD_STAT was needed in
this case. They would not be likely to look at the .m4 files when a
compile fails.

The autoconfig/automake tools do not work yet on VMS. There is a
volunteer trying to make it work, but based on how much time they have
had recently it looks like it will be a while before that is an option.

It has only been a short while that the GNV project has been able to run
the configure scripts on VMS. And we are still having issues trying to
get make check to work in some cases.

We do not use Configure scripts for building Bash, Coreutils, gawk, sed,
and the make fork, as we need to build at least these first to get the
configure scripts to run.

Regards
-John
Paul Eggert
2017-06-05 05:22:09 UTC
Permalink
Raw Message
I do not know if the pragma for the assert would be valid for anything other
than __DECC compiler
Ah, I see. Still, I'm leery of pragmas, as I have the sneaking suspicion that
they can hurt even when inside an #else that is skipped, due to problems in
parsing them on non-VMS platforms. So if we can do without the pragma I'd prefer
that.
The autoconfig/automake tools do not work yet on VMS.
That's OK, they don't need to. You can run them on GNU/Linux, and then run the
resulting 'configure' script on VMS, once you get the shell working.
We do not use Configure scripts for building Bash, Coreutils, gawk, sed, and the
make fork, as we need to build at least these first to get the configure scripts
to run.
Once you get them running they should be self-supporting. In the meantime you
can just use -D_USE_STD_STAT systematically in your compiler switches. The
Gnulib source code generally does not worry about development platforms that
don't have a working shell, as that's too far away from the intended porting target.
Loading...