Is --with-zlib=bundled broken on MacOS aarch64 12.2.1?

[Jaikiran Pai]

On 29/03/22 6:12 pm, David Holmes wrote:
> On 29/03/2022 7:20 pm, Magnus Ihse Bursie wrote:
>> On 2022-03-29 03:42, Jaikiran Pai wrote:
>>> Hello Magnus,
>>>
>>> On 28/03/22 5:21 pm, Magnus Ihse Bursie wrote:
>>>> On 2022-03-28 09:03, David Holmes wrote:
>>>>> On 28/03/2022 4:56 pm, Alan Bateman wrote:
>>>>>> On 28/03/2022 07:46, David Holmes wrote:
>>>>>>> Hi Jai,
>>>>>>>
>>>>>>> It isn't obvious to me that the bundled sources are actually 
>>>>>>> intended to build on macOS. There's no include of unistd.h to 
>>>>>>> get the lseek definition.
>>>>>> I think the context here is that Jai is chasing an issue that may 
>>>>>> be bug in the libz on macOS. Building the bundled version and 
>>>>>> comparing results would lead to useful information. AFAIK, the 
>>>>>> system zlib has always been used since 7u4 when the macOS was 
>>>>>> added. I think the Apple JDK did the same. So there may be a 
>>>>>> small bit of "porting" to do, adds include files, etc.
>>>>>
>>>>> Okay, I suggest adding the include of unistd.h as a starter then. 
>>>>> But Jai should note that this is not a build issue per-se - making 
>>>>> those sources buildable on all desired platforms is the job of the 
>>>>> owners of that src in the OpenJDK.
>>>> I agree fully, but I'd also like to add that it is not clear that 
>>>> this is not "supposed" to work. If bundled zlib is not buildable on 
>>>> macOS (that was news to me), then the correct build system behavior 
>>>> should have been to block it in configure. So, Jaikiran, if you 
>>>> intend to get this to work on macOS, great! If you're not taking 
>>>> that route, please let me know so I can open a bug on prohibiting 
>>>> bundled zlib on maccOS from configure.
>>>>
>>> I used David's suggestion to add that include header:
>>>
>>> diff --git a/src/java.base/share/native/libzip/zlib/gzlib.c 
>>> b/src/java.base/share/native/libzip/zlib/gzlib.c
>>> index a814dd8c7b6..9df629d4205 100644
>>> --- a/src/java.base/share/native/libzip/zlib/gzlib.c
>>> +++ b/src/java.base/share/native/libzip/zlib/gzlib.c
>>> @@ -35,6 +35,7 @@
>>>  #if defined(_LARGEFILE64_SOURCE) && _LFS64_LARGEFILE-0
>>>  #  define LSEEK lseek64
>>>  #else
>>> +#  include <unistd.h>
>>>  #  define LSEEK lseek
>>>  #endif
>>>  #endif
>>>
>>> That did help me get past the lseek error, but there are some more 
>>> errors (as noted in that log) which need to be addressed too. I 
>>> don't have the necessary knowledge of C ecosystem to decide what set 
>>> of includes and whether those includes need to be conditional for 
>>> macOS, are required to get this building. The other thing to 
>>> consider with this code is that it is bundled code and the real code 
>>> lies in a separate upstream zlib project[1]. So I think whatever 
>>> changes we do here might have to be co-ordinated back to that project.
>> Maybe. But when we bundle code we also kind of rip it out of context. 
>> It might very well be that the upstream code has an automake system 
>> which generates a config.h that has proper includes and defines to 
>> get this to build. I mean, obviously there is an existing system zlib 
>> on macOS, so *someone* has gotten it to build.
>
> Our sources are for a very old version:
>
> 1.2.11 (15 Jan 2017)
>
Until 2 days back, that was the latest released version of that library. 
A couple of days back 1.2.12 has been released (or at least tagged) 
https://github.com/madler/zlib/tags


-Jaikiran