<AWT Dev> RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure

[Phil Race]

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.

-phil.

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 [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:
>>
>> 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,
> Reference should have been:
>
> [0] https://bugs.openjdk.java.net/browse/JDK-8081315