<AWT Dev> [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file or directory"

Philip Race philip.race at oracle.com
Thu Nov 29 04:24:58 UTC 2018


Not something we want to do if there's any way out of it.

can we just disable PNG_SET_OPTION_SUPPORTED in
pnglibconfig.h which is something that is "generated" and not part of 
the png source ?

I don't see anything that is important enabled by that option.

-phil.


On 11/28/18, 3:38 PM, Erik Joelsson wrote:
> Looks ok to me if we are fine with making changes to libpng source. I 
> thought this was usually not something we wanted to do with upstream 
> sources.
>
> /Erik
>
> On 2018-11-28 15:11, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212680
>> Webrev: http://cr.openjdk.java.net/~serb/8212680/webrev.00
>>
>> On Solaris we faced the bug which was fixed in macOS already:
>>   https://bugs.openjdk.java.net/browse/JDK-8196803
>>
>> The problem is that there is a call to "inflateValidate" function in 
>> pngrutil.c[1], guarded by a preprocessor check of ZLIB_VERNUM being 
>> high enough and by the "PNG_IGNORE_ADLER32". If we compile this call 
>> in and link to the newer version of zlib, we will get link errors if 
>> the code is executed on an older Mac/Solaris/ with an older version 
>> of zlib.
>>
>> The bug can be reproduced on "old" Solaris 11.3, which was not 
>> updated for a while(since 2015).
>>
>> We can fix it by requiring some "OS Patches and Package Updates", but 
>> since it was
>> reproduced on macOS, and potentially can occur on other platforms, I 
>> have decided
>> to fix it in the code. The new property is introduced to the libpng 
>> "PNG_ADLER32_SUPPORTED",
>> which control the usage of "PNG_IGNORE_ADLER32" and as a result 
>> control the call to "inflateValidate"[1].
>> This new property is set in the makefile when we build "bundled" 
>> versions of libpng+zlib only.
>>
>> This was reported upstream, and the future version of libpng may have 
>> some similar solution.
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk/jdk/file/396dfb0e8ba5/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c#l457
>>
>>



More information about the build-dev mailing list