<AWT Dev> RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure
philip.race at oracle.com
Fri May 29 04:41:06 UTC 2015
Looks OK to me. I've added 2d-dev (owner of the lib).
I don't think this will cause any issue for closed builds but we'll
address it if it does.
On 5/28/15 7:25 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081447
>> Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/
>> In testing a fix for , 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
>> ifeq ($(USE_EXTERNAL_LIBJPEG), true)
>> BUILD_LIBJAVAJPEG_HEADERS :=
>> BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC))
>> but then BUILD_LIBJAVAJPEG_HEADERS is not used and
>> instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in
>> 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?
> Reference should have been:
>  https://bugs.openjdk.java.net/browse/JDK-8081315
More information about the build-dev