PATCH: large file support on SunOS 5

PATCH: large file support on SunOS 5

[Peter Stephenson]

This is the patch for large file support on SunOS 5 using the configuration
code lifted from bash.  There was one additional difficulty that $LDFLAGS
was always set, so that $auto_ldflags has to be tested to see if it was set
by configure.

--- aczsh.m4.2gb	Sat Jan  9 17:12:41 1999
+++ aczsh.m4	Thu May  6 16:58:50 1999
@@ -25,6 +25,47 @@
 dnl
 
 dnl
+dnl Code from the configure system for bash 2.03 (not zsh copyright).
+dnl If available, use support for large files unless the user specified
+dnl one of the CPPFLAGS, LDFLAGS, or LIBS variables (<eggert@twinsun.com>
+dnl via GNU patch 2.5)
+dnl
+AC_DEFUN(zsh_LARGE_FILE_SUPPORT,
+[AC_MSG_CHECKING(whether large file support needs explicit enabling)
+ac_getconfs=''
+ac_result=yes
+ac_set=''
+ac_shellvars='CPPFLAGS LDFLAGS LIBS'
+for ac_shellvar in $ac_shellvars; do
+  case $ac_shellvar in
+  CPPFLAGS) ac_lfsvar=LFS_CFLAGS ac_lfs64var=LFS64_CFLAGS ;;
+  *) ac_lfsvar=LFS_$ac_shellvar ac_lfs64var=LFS64_$ac_shellvar ;;
+  esac
+  eval test '"${'$ac_shellvar'+set}"' = set && ac_set=$ac_shellvar
+  (getconf $ac_lfsvar) >/dev/null 2>&1 || { ac_result=no; break; }
+  ac_getconf=`getconf $ac_lfsvar`
+  ac_getconf64=`getconf $ac_lfs64var`
+  ac_getconfs=$ac_getconfs$ac_getconf\ $ac_getconf64
+  eval ac_test_$ac_shellvar="\$ac_getconf\ \$ac_getconf64"
+done
+case "$ac_result$ac_getconfs" in
+yes) ac_result=no ;;
+esac
+case "$ac_result$ac_set" in
+yes?*) test "x$ac_set" != "xLDFLAGS" -o "x$auto_ldflags" = x && {
+  ac_result="yes, but $ac_set is already set, so use its settings"
+}
+esac
+AC_MSG_RESULT($ac_result)
+case $ac_result in
+yes)
+  for ac_shellvar in $ac_shellvars; do
+    eval $ac_shellvar=\$ac_test_$ac_shellvar
+  done ;;
+esac
+])
+
+dnl
 dnl zsh_SYS_DYNAMIC_BROKEN
 dnl   Check whether static/shared library linking is broken.
 dnl
--- configure.in.2gb	Mon May  3 16:38:10 1999
+++ configure.in	Thu May  6 16:36:15 1999
@@ -204,6 +204,10 @@
 
 AC_PROG_CC
 
+dnl Check for large file support (Solaris).
+dnl This needs to be done early to get the stuff into the flags.
+zsh_LARGE_FILE_SUPPORT
+
 dnl if the user hasn't specified CFLAGS, then
 dnl   if compiler is gcc, then use -O2 and some warning flags
 dnl   else use -O

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Possible impact of RE: PATCH: large file support on SunOS 5

[Andrej Borsenkow]

The LFS_CFLAGS (or, for that matter, LFS64_CFLAGS) make the off_t and ino_t
64 bit long. Dunno about Solaris, but at least on our system they are of
type "long long" and there is no standard portable way to print 64 bit
integers (if sizeof(long) < 8). Our system is using %lld; Solaris is using
%qd if I'm not wrong.

This has impact at least on stat module (and possibly others) that print
file size and inode. It has possible impact on zftp module that has to
correctly count transferred bytes (and our ftp is able to transfer more than
2GB - I'd expect it from zftp as well).  And may be some others.

What I want to say - it is not enough to simply compile a program with
correct flags - program must be able to correctly handle large files.

Can anybody who knows zsh internals better confirm, that zsh is really able
to handle large files?

/andrej

P.S. I am running zsh in LP64 mode for quite a long time. This is different,
as in this case all of off_t, ino_t and long are 8 bytes, so nothing in the
code changes. May be, if a system supports LP64 we should prefer it to LFS?

Re: Possible impact of RE: PATCH: large file support on SunOS 5

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> The LFS_CFLAGS (or, for that matter, LFS64_CFLAGS) make the off_t and ino_t
> 64 bit long. Dunno about Solaris, but at least on our system they are of
> type "long long" and there is no standard portable way to print 64 bit
> integers (if sizeof(long) < 8). Our system is using %lld; Solaris is using
> %qd if I'm not wrong.

This will take a little work, but perhaps it's not so bad.  off_t is
checked for in configure.  It needs to be propagated where it occurs in the
sources, e.g. in an .st_size member, instead of being assigned to longs (I
don't think that happens much anyway, but I could be wrong).  For printing,
one of %lld or %qd will probably work; there's already a test for %qd in
the rlim_t test in configure, which can be made more general.  ino_t isn't
tested in configure so probably needs adding in the same way.

I already have several things to finish off, so maybe someone else will
feel like looking at this first (although maybe hell will freeze over while
I wait :-)).

> P.S. I am running zsh in LP64 mode for quite a long time. This is different,
> as in this case all of off_t, ino_t and long are 8 bytes, so nothing in the
> code changes. May be, if a system supports LP64 we should prefer it to LFS?

I have no idea how to do this.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: Possible impact of RE: PATCH: large file support on SunOS 5

[Andrej Borsenkow]

>
> This will take a little work, but perhaps it's not so bad.

It just occured to me, that actually things _are_ bad. Assume, that you have
generic zsh script that takes stat output and makes some computation ... the
simple thing is size(file) < free_space ... and hits a large file (and even
free space is already dangerous - I'm currently running with 9GB filesystem.
It's O.K.in blocks - but not in bytes). This would mean, that all internal
computation should be done in 64 bits ... too bad really (problem with zftp
I mentioned is exactly of this nature)

In other words, really subtle problems may arise. That is exactly the reason
why I'd prefer LP64 mode that does not have these problems.
>
> I have no idea how to do this.
>

Well, we need to have a list of possible compiler flags that force LP64
mode. Our system is using -Klp64. IRIX? Solaris? Linux? Somebody's written,
that zsh runs on Irix in LP64 mode. Gotta look in archive.


/andrej