On Sat, 20 Jan 2024 07:34:34 GMT, Alan Bateman <al...@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 <s...@gentoo.org> >> - buf64->buf >> >> Signed-off-by: Sam James <s...@gentoo.org> >> - Add message for assert >> >> Not all C++ stds implement it w/o. >> - Add off_t static_asserts >> >> Signed-off-by: Sam James <s...@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 <s...@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
