CVS source on or after June 6th has problems

[jtrostel at connex.com]

I am building on a (modified) Linux 6.2+ system with glibc 2.1.92

On 18-Jun-2001 Jeremy Allison wrote:
> jtrostel at connex.com wrote:
>> 
>> The problem seems to lie in the addition of -D_FILE_OFFSET_BITS=64 in two
>> places in the configure.in file.  Jeremy added this fix to the CVS tree on
>> June
>> 6th.  If I remove these entries, all works again.
>> 
>> Why were these entries added? (And why do they break our builds?)
> 
> What platform are you building on ? If Linux, what glibc version ?
> 
> To get LFS support on Linux I ensured the following were
> defined (from the glibc info pages on RedHat 7.1) :
> 
>  - Macro: _LARGEFILE64_SOURCE
>      If you define this macro an additional set of functions is made
>      available which enables 32 bit systems to use files of sizes beyond
>      the usual limit of 2GB.  This interface is not available if the
>      system does not support files that large.  On systems where the
>      natural file size limit is greater than 2GB (i.e., on 64 bit
>      systems) the new functions are identical to the replaced functions.
>  
>      The new functionality is made available by a new set of types and
>      functions which replace the existing ones.  The names of these new
>      objects contain `64' to indicate the intention, e.g., `off_t' vs.
>      `off64_t' and `fseeko' vs. `fseeko64'.
>  
>      This macro was introduced as part of the Large File Support
>      extension (LFS).  It is a transition interface for the period when
>      64 bit offsets are not generally used (see `_FILE_OFFSET_BITS').
> 
> - Macro: _FILE_OFFSET_BITS
>      This macro determines which file system interface shall be used,
>      one replacing the other.  Whereas `_LARGEFILE64_SOURCE' makes the
>      64 bit interface available as an additional interface,
>      `_FILE_OFFSET_BITS' allows the 64 bit interface to replace the old
>      interface.
>  
>      If `_FILE_OFFSET_BITS' is undefined, or if it is defined to the
>      value `32', nothing changes.  The 32 bit interface is used and
>      types like `off_t' have a size of 32 bits on 32 bit systems.
>  
>      If the macro is defined to the value `64', the large file interface
>      replaces the old interface.  I.e., the functions are not made
>      available under different names (as they are with
>      `_LARGEFILE64_SOURCE').  Instead the old function names now
>      reference the new functions, e.g., a call to `fseeko' now indeed
>      calls `fseeko64'.
>  
>      This macro should only be selected if the system provides
>      mechanisms for handling large files.  On 64 bit systems this macro
>      has no effect since the `*64' functions are identical to the
>      normal functions.
>  
>      This macro was introduced as part of the Large File Support
>      extension (LFS).
> 
> As far as I can tell, adding both is a "belt and braces"
> approach to getting LFS.
> 
> Samba detects 64 bit file support at configure time, and sets
> the define HAVE_EXPLICIT_LARGEFILE_SUPPORT, and also detects
> the existance of open64() and friends. lib/system.c then selects
> what underlying call to use depending on the sizes of things
> like off_t or the existance of off64_t and stat64().
> 
> Jeremy.
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel at connex.com