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

Reply via email to