Fix for libpng undefined symbol
fitzsim at redhat.com
Mon Aug 20 15:34:31 PDT 2007
Hans de Goede wrote:
> Thomas Fitzsimmons wrote:
>> 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:
>> 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.
> 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.
More information about the distro-pkg-dev