Thanks a lot Phil and Sergey! I've just pushed the change.
Regards, Volker On Tue, Sep 9, 2014 at 8:37 PM, Sergey Bylokhov <[email protected]> wrote: > 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 <[email protected]> >>> 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. >
