Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken
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.
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.
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.
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?
Reply to: