On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <i...@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
