[PATCH] Deprecate 32-bit off_t support

[Adhemerval Zanella]

On 18/01/2019 08:09, Florian Weimer wrote:
> * 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.

It is not clear to me if packages are being built without LFS due wrong
configure/build options, lack of support from distro built system, or
explicit disabling in package build (due either lack of testing or
ABI limitation).

Also, it is really questionable to have a system with mixed LFS support 
for libraries specially the one that might export off_t in its API.

My impression is, for system consistency, have all libraries with explicit
LFS support and handle outliers as why the program/libraries is building 
*without* non-LFS support (not the other way around).