[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken



   Date: Sat, 29 Jul 2000 00:03:06 -0700 (PDT)
   From: Paul Eggert <eggert@twinsun.com>

      From: Mark Kettenis <kettenis@wins.uva.nl>
      Date: Sat, 29 Jul 2000 01:22:03 +0200

	 Date: Sat, 29 Jul 2000 00:27:09 +0200
	 From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

	 The culprit is that fileutils now defines _FILE_OFFSET_BITS 64
	 on the Hurd, which sucks in functions like readdir64, lseek64

   Sorry, this is the first I've heard of the problem.  What does "sucks
   in functions" mean?  Does the program try to link these functions,
   even though they don't exist?  If so, "configure" could catch that
   problem by trying to linking a program that sets _FILE_OFFSET_BITS to
   64 and invokes lseek; if the link doesn't work, then "configure" could
   avoid setting _FILE_OFFSET_BITS to 64.

The Hurd uses the GNU C Library, and basically the same header files
as on Linux (only the `bits' differ).  This means that setting
_FILE_OFFSET_BITS has basically the same effect on Linux, except that
some of the *64() calls are implemented as stubs returning ENOSYS.  To
assist autoconf, <gnu/stubs.h> defines:

#define __stub_fstatfs64
#define __stub_fstatvfs64
#define __stub_glob64
#define __stub_lstat64
#define __stub_posix_fadvise64
#define __stub_readdir64
#define __stub_readdir64_r
#define __stub_stat64
#define __stub_statfs64
#define __stub_statvfs64

and if you link against the functions you'll get a `foo64 is not
implemented and will always fail' message.

	 Funnily, the autoconf check doesn't bother to check if largefiles
	 are really supported.

   What do you mean by "really supported"?  I'd prefer checks that
   can be done at compile or link time, for cross-compilation.

I'd suggest testing for one of the *64() functions in the list above.
If you tell me which one, I'll make sure that'll be the last one
for which we add a "real" implementation.

      We don't advertise that we support large files on the Hurd.  If we
      did, we would set one of more of the following macros to 1 in
      <unistd.h>:

      _LFS_LARGEFILE

   I don't know that those macros are reliable.  E.g. I suspect that some
   AIX and/or HP-UX hosts don't define them, even though they have large
   files.  (Unfortunately I don't have access to those hosts to test my
   theory.)  The LFS specs are not always followed, so I'd like autoconf
   to use a more direct test if possible.

That would mean a compile time check for one of the *64() functions listed
above (AC_CHECK_FUNC checks the __stub_* macros mentioned above) or a
link time check for the warning.

   Apparently the Hurd grow off_t from 32 to 64 bits when the programmer
   sets _FILE_OFFSET_BITS to 64.  Why does the Hurd do this if it doesn't
   support large files, at least to some extent?  In other words, to what
   extent does the Hurd support large files?

The Hurd doesn't really support large files at all.  The filesystems
cannot handle partitions larger than ~1 GB, and there is no support
for the 64-bit interfaces in the "kernel".

We have definitions for most of the types and structures, "just to make
the GNU C Library compile".

By the way, I believe there are older versions of the GNU C Library
thet even on Linux do not implement some of the *64() interfaces.

Mark



Reply to: