Re: [Dump-devel] dump and largefiles

[<ty...@va...>]

   Date: Tue, 19 Dec 2000 22:18:09 +0100
   From: Andrea Arcangeli <an...@su...>

   I dislike to see the explicit LFS interface. I like not having to write
   O_LARGEFILE and truncate64 in the sources for example. This because on 64bit
   platform I can avoid to compile with --enable-largefile and the source code
   remains the same: without alien things like O_LARGEFILE and truncate64 inside.

At least at the source level, I can easily hide the need for O_LARGEFILE
and lseek64 in specific library routines, and it's easy enough to have
autoconf macros that only use O_LARGEFILE and use lseek64 if present
(and even then, I only use it when necessary).

   About trustlevel of glibc folks I believe they're forced to get this
   interface right on the long run (unfortunately).  Now that we have
   this stuff supported I can at least take advantage of it at the
   source level.

I'm worried about ABI compatibility for glibc's both with and without
LFS support (i.e., glibc 2.1 and glibc 2.2; never mind glibc 2.0
compatibility).

   About the librarians issue I'm not sure (what matters for the ABI is the
   interface [not if the library internally recalls truncate or truncate64 in its
   way while doing its work] and none librarians other than glibc is supposed to
   provide those VFS calls so interface shouldn't break that easily). But
   as said I'm not sure about this...

The problem with using the #define method is that it changes the size of
off_t.  So libraries built with and without -D_LARGE_FILE_SIZE=64 
have ABI changes if any of their function prototypes or structures
contain off_t.  This is bad, bad, bad, bad, bad.  *Especially* for
shared libraries.  

						- Ted