Re: [PATCH] Deprecate 32-bit off_t support

[Florian Weimer <fweimer at redhat dot com>]

* Guillem Jover:

> Hi!
>
> On Fri, 2019-01-04 at 13:39:59 +0100, Florian Weimer wrote:
>> diff --git a/NEWS b/NEWS
>> index cc20102fda..2f601c6217 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -85,6 +85,15 @@ Deprecated and removed features, and other changes affecting compatibility:
>>    as all functions that call vscanf, vfscanf, or vsscanf are annotated with
>>    __attribute__ ((format (scanf, ...))).
>>  
>> +* A future release of glibc will use a 64-bit off_t type on all
>> +  architectures (as currently available with -D_FILE_OFFSET_BITS=64 on
>> +  32-bit architectures).  Building new applications with
>> +  -D_FILE_OFFSET_BITS=32 will no longer be supported.  The off64_t type and
>> +  the 64-bit function aliases (such as fstat64) will remain available under
>> +  the appropriate feature test macros.  In preparation, libraries should
>> +  stop using off_t in public header files, and use off64_t (or a fixed-width
>> +  type such as int64_t or uint64_t) instead.
>> +
>>  Changes to build and runtime requirements:
>>  
>>  * Python 3.4 or later is required to build the GNU C Library.
>
> While I'm fully behind further pushing to get software to switch to
> build (and work) with LFS (that's the reason I proposed the below lintian
> tag some time ago), it feels that something like the above might still be
> a bit too aggressive? :/
>
> For example in Debian that would probably imply not being able to
> upgrade to such glibc until at least all shared libraries and packages
> supporting and implementing plugins listed at
>
>   <https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>
>
> have been transitioned (with either SONAME bumps, or package renames
> with Breaks/Conflicts), or determined to not affect their ABI. Please
> notice at the top, the comment about that page only having a truncated
> view of the affected packages; in addition there might be other packages
> not being currently detected.

What's interesting is what is *not* in this list.  As far as I can see,
the non-cross binutils is missing, and so are Berkeley DB and
parts/versions of of LLVM.  What's common among them is that they
install public header files under /usr/include which use off_t in the
API.  So these ABIs already assume that client code is compiled with
-D_FILE_OFFSET_BITS=64.

Sure, some corner cases may break when we change the default, but other
things will magically start working.  I think it is worth a try.

Thanks,
Florian