On 08/28/2008 08:33 PM Martin Buchholz wrote:
I'm thinking:
- the MMX support is in pnggccrd.c,
- but that file is never compiled in OpenJDK
Why? There's the following line in the make/sun/splashscreen/Makefile:
vpath %.c $(SHARE_SRC)/native/$(PKGDIR)/libpng
that effectively includes all *.c files in the libpng sources directory
(src/share/native/sun/awt/libpng/) in the compilation process. Honestly,
to me this seems to be a problem with the #ifdef's/#define's logic in
libpng, rather than the strong necessity to disable MMX support at all.
At least the correct working of this code on MS Windows and 32-bit Linux
systems (if compiling using the recommended build environment) somewhat
proves this point of view.
--
best regards,
Anthony
- so... how could png ever work when PNG_NO_MMX_CODE is not defined,
on any platform?
I am suspicious that png splashscreens are actually broken
without my proposed patch. Has this actually been tested?
I googled a little and have a theory.
"-z defs" is supposed to be ignored for shared libs
(but why are we using it to build libsplashscreen.so?)
but very recent gcc toolchains don't ignore it the way they
perhaps should.
E.g. Here's a debian bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142
On hppa -Wl,-z,defs is not ignored for shared libraries
But using "-z defs" is actually good engineering practice,
since it catches problems at link time instead of run time.
Whether or not it's a bug in my toolchain, my toolchain
detects the unsatisfied symbols in the link.
There's a good chance that my change will be necessary
to build OpenJDK on future stock Linux systems.
