RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
Sam James
duke at openjdk.org
Fri Feb 2 07:01:05 UTC 2024
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>
> Add kludge to BufferedRenderPipe.c for AIX
First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign.
> > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers.
>
> I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code.
>
> To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...)
Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine.
Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK.
I'll leave comments inline for the rest.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781
More information about the serviceability-dev
mailing list