Re: using _FILE_OFFSET_BITS=64 with a non-gcc compiler

[Paul Eggert <eggert at twinsun dot com>]

> From: Ulrich Drepper <drepper@redhat.com>
> Date: 12 Nov 2001 09:50:06 -0800
> 
> There is no way the transparent renaming can work corectly and sanely
> without compiler support.  All compilers which have to handle this do
> (just look at Solaris).

True, but using Solaris as a precedent actually argues for something
like Bruno's patch, because because Solaris's headers work correctly
and sanely only with Sun's compilers.  For other compilers (e.g. GCC
3.0.2) Solaris's headers fall back on a solution that changes the
namespace, much like Bruno's proposed patch does.

Here's an example of how it works, for the case where long is 32 bits,
long long is 64 bits, __STDC__ is defined, and _LARGEFILE64_SOURCE is
not defined.  In this case, the Solaris 8 <dirent.h> defines readdir
as follows:

   #ifdef __PRAGMA_REDEFINE_EXTNAME
   # pragma redefine_extname readdir readdir64
   #else
   # define readdir readdir64
   #endif

   extern struct dirent *readdir(DIR *);

Sun's compiler supports redefine_extname, but GCC doesn't, so this
approach changes the application namespace when GCC is used, since
dirent.h usurps the name readdir64 and doesn't allow the user to
#undef readdir.

I know that the Solaris+GCC solution does not conform to POSIX, but it
works pretty well in practice.


> Simply disable LFS for such compilers.

I'm sympathetic to your desire to avoid mucking with the namespace,
but disabling LFS is pretty extreme.  Most application programmers
want functionality more than they want pedantic POSIX support.