Fix for libpng undefined symbol

[Thomas Fitzsimmons]

Hans de Goede wrote:
> Thomas Fitzsimmons wrote:
>> Hi,
>>
>> With the update to b18 the build was failing on my x86_64 machine with 
>> an undefined symbol, png_mmx_support, in libpng.
>>
>> The problem was exposed by the fix for:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6577886
>>
>> specifically this line:
>>
>> +LDFLAGS_DEFS_OPTION  = -z defs
>>
>> which causes the linker to disallow undefined symbols.
>>
>> The failure will happen on systems that support MMX:
>>
>> $ echo | cpp -dM | grep __MMX__
>> #define __MMX__ 1
>>
>> That macro indirectly causes the default png_mmx_support definition to 
>> be ifdef'd out.
>>
>> For now I've applied this workaround:
>>
>> --- openjdk.orig/j2se/make/sun/splashscreen/Makefile    2007-08-19 
>> 15:04:21.000000000 -0400
>> +++ openjdk/j2se/make/sun/splashscreen/Makefile 2007-08-19 
>> 15:08:45.000000000 -0400
>> @@ -59,7 +59,7 @@
>>  # C Flags
>>  #
>>
>> -CFLAGS += -DSPLASHSCREEN
>> +CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE
>>
>>  ifneq ($(PLATFORM), windows)
>>    CFLAGS += -DWITH_X11
>>
>> to disable libpng's MMX-specific functions (optimized C 
>> implementations are used instead).
>>
>> A better solution would be to conditionally compile pnggccrd.c, which 
>> defines png_mmx_support, when __MMX__ is defined.  pnggccrd.c would 
>> have to be patched to fix png_squelch_warnings compile errors.
>>
> 
> Hmm,
> 
> This sounds awefully familiar to a bug in the system libpng, which I 
> fixed quite some time ago. Is IcedTea using its own copy of libpng? IF 
> so why?

OpenJDK bundles its own copy of libpng.  There are no significant differences 
between the bundled copy and Fedora 7's.  I assume it's done for portability to 
systems that don't have libpng, but for Fedora I agree that IcedTea should use 
the system libpng.

Tom