$SUBJECT says it all, libjpeg-turbo no longer defines some macros (like JPP) breaks builds of dependent packages (including digikam, gwenview, reportedly others according to -devel list) Seems to be on purpose, http://sourceforge.net/p/libjpeg-turbo/mailman/message/32677570/ But I'd argue it's still not nice to break (even implicit) API in public headers like this.
See also, gwenview FTBFS bug #1163476 and upstream digikam FTBFS bug https://bugs.kde.org/show_bug.cgi?id=340944
See also firefox failure caused too, https://bugzilla.mozilla.org/show_bug.cgi?id=1093615
and devel list thread, https://lists.fedoraproject.org/pipermail/devel/2014-November/203997.html
I see the same issue trying to build a new libpano13 package: /builddir/build/BUILD/libpano13-2.9.19/jpegicc.c:271:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token JOCTET FAR *src_ptr; ^
Upstream is informed. I am waiting for response vie JPP macros were removed.
The mailing list message that you linked to above says it all. The macros were removed because modern compilers do not need them. The macros were included originally in libjpeg because some very old compilers did not support prototype parameters. Those non-ANSI compilers are no longer supported by us, and I'm pretty sure that the packages that are failing to build no longer support non-ANSI compilers either (if they ever did.) The packages in question most likely used the JPP() and JMETHOD() macros just because they were trying to follow the format of the libjpeg header files. There is no way I could have known that 3rd party packages would be using those macros. Such a practice was never necessary, nor do I personally think it was very good form on the part of the 3rd party packages. If those packages actually did need to support ancient non-ANSI compiler, then they should have taken steps to ensure their own local support for those compilers instead of using libjpeg's macros. That being said, I do accept the argument that, since those macros were in the exposed header files, they could be considered part of the API. Ugh. That's what I get for trying to do the right thing. I've checked in a patch to libjpeg-turbo SVN trunk and branches/1.4.x that should resolve this.
Thanks!
Many of the failures appear to come from a file called iccjpeg.c or jpegicc.c, I guess this is the same source file that got copied and pasted all over the place.
scm-commit for this bug http://pkgs.fedoraproject.org/cgit/libjpeg-turbo.git/commit/?id=403a5a16e37314547a45c6df6cf2bd6a057a2c66 DRC thanks for your fast fix in upstream. Awesome.