[OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build

[Sergey Bylokhov]

The fix looks fine to me too.

On 09.09.2014 22:18, Phil Race wrote:
> Approved
>
> -phil.
>
> On 09/09/2014 11:11 AM, Volker Simonis wrote:
>> Hi,
>>
>> I've updated my webrev to reflect the fix which has now been pushed to
>> LittleCMS mainline. It renames SNONE to SUNDEFINED :-
>> https://github.com/mm2/Little-CMS/commit/5bc4f52ff6b2090863d824827a871cd6274e36e4 
>>
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8057934.v1/
>>
>> Pease review.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: and I've verified that SUNDEFINED isn't defined on AIX...
>>
>>
>> On Tue, Sep 9, 2014 at 3:51 PM, Volker Simonis 
>> <volker.simonis at gmail.com> wrote:
>>> Hi,
>>>
>>> could you please review the following tiny fix for an AIX build
>>> problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6":
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8057934/
>>> https://bugs.openjdk.java.net/browse/JDK-8057934
>>>
>>> The problem is that the new version of LittleCMS now includes
>>> "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in
>>> turn includes "sys/proc.h" which uncoditionally defines a preprocessor
>>> constant "SNONE".
>>>
>>> In "cmscgats.c" this preprocessor constant "SNONE" collides with the
>>> enum value "SNONE" from the SYMBOL enumaration.
>>>
>>> The only solution I see is to rename "SNONE" in "cmscgats.c". I
>>> renamed it to "SVOID" but would be happy with any other name.
>>> Fortunately "SNONE" is only used locally in the file "cmscgats.c", so
>>> renaming it won't have any impact on other files.
>>>
>>> Once this bug is fixed I'll report the problem upstream to LittleCMS
>>> and try to get the fix in there.
>>>
>>> Finally, there's on last point I wan to bring up. I realized that
>>> "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right
>>> into 8u-dev. That's why we caught this error only in 8u-dev and not
>>> already in jdk9-dev which we build on a daily basis on all our porting
>>> platforms. Is my assumption that changes have to through jdk9-dev
>>> before they get back ported wrong or has this been an exeption?
>>>
>>> Thank you and best regards,
>>> Volker
>


-- 
Best regards, Sergey.