Date: Sat, 29 Jul 2000 00:03:06 -0700 (PDT)
From: Paul Eggert <[EMAIL PROTECTED]>
From: Mark Kettenis <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2000 01:22:03 +0200
Date: Sat, 29 Jul 2000 00:27:09 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
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
