----- Original Message ----- > On 2015-05-29 04:24, Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 Webrev: > http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ In testing a fix for > [0], I found that system jpeg support seems > to have bitrotted. Due to the movement of makefiles, it's hard > to trace where this change occurred, but we have the conditional > code: > > It was a casualty of JDK-8054834 (Modular Source Code ). >
Yes, I traced it to that changeset, but it wasn't clear if it was actually changed there or the file was simply moved then. > Thanks for the fix, it looks good to me. My thanks to yourself and Phil. I've pushed the fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6f87fd2df0d6 > > /Magnus > > > > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > BUILD_LIBJAVAJPEG_HEADERS := > else > BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > endif > > but then BUILD_LIBJAVAJPEG_HEADERS is not used and > instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in > BUILD_LIBJAVAJPEG: > > CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ > > When building using the system libjpeg, this means that the jpeglib.h > from the in-tree copy of libjpeg is used to build jpegdecoder.o. This > leads to references to symbols that don't exist in the system version > and a failure to link libjavajpeg.so > > The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, > as in the listed webrev. > > Ok to push to client? > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07