RFR: 8318696: Do not use LFS64 symbols on Linux [v5]

[Alan Bateman]

On Sat, 20 Jan 2024 07:34:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sam James has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge master
>>  - crank copyright
>>  - sendfile64 -> sendfile
>>    
>>    Signed-off-by: Sam James <sam at gentoo.org>
>>  - buf64->buf
>>    
>>    Signed-off-by: Sam James <sam at gentoo.org>
>>  - Add message for assert
>>    
>>    Not all C++ stds implement it w/o.
>>  - Add off_t static_asserts
>>    
>>    Signed-off-by: Sam James <sam at gentoo.org>
>>  - Do not use LFS64 symbols on Linux
>>    
>>    The LFS64 symbols provided by glibc are not part of any standard and
>>    were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in
>>    1.2.5). This commit replaces the usage of LFS64 symbols with their
>>    regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions
>>    will always act as their -64 variants on glibc.
>>    
>>    Signed-off-by: Sam James <sam at gentoo.org>
>
> I assume a separate issue will be needed for the JDK native libraries as there are quite a few LFS64 usages.

> @AlanBateman @thesamesam I opened [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539) for the JDK libs. The implementation is trivial (#17538) but I am not sure how to understand the impact. My gut feeling is that if anything was wrong with this it would not even compile, but I need to understand this properly.

Doesn't it mean going over the native code and replacing the LFS64 symbols with their regular counterparts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1906382096