Summary: | Build failed against libjpeg-turbo-1.3.90 | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | nucleo <nucleo> |
Component: | Portability-Compilation | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | caulier.gilles, rdieter |
Priority: | NOR | ||
Version: | 4.5.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Other | ||
Latest Commit: | Version Fixed In: | 7.6.0 | |
Sentry Crash Report: | |||
Attachments: |
workaround build failures with newer libjpeg-turbo builds
patch to MacroJPEG.cmake to check jpeg lib definitions |
Description
nucleo
2014-11-14 05:49:13 UTC
Sound jpeg turbo do not respect API compatibilty for client applications.... Why ??? Gilles Caulier I don't know why, maybe libjpeg-turbo bug. The problem being that libjpeg-turbo recent versions no longer define JPP macro, per the downstream gwenview bug, one possible quick-n-dirty solution is to add to digikam (after libjpeg includes): #ifndef JPP #define JPP(x) x #endif Rex, Why jpeg turbo have removed this define ? It sound like an upstream problem no ? Gilles Caulier As, i can seen, jpeg turbo 1.3.90 is 1.4 beta1 in fact. This problem which break compatibility with client applications must be reported as upstream to jpeg turbo team. Gilles Caulier I found this upstream ml thread, http://sourceforge.net/p/libjpeg-turbo/mailman/message/32677570/ I got gweview to build with a a few extra defines, let's see if I can do the same for digikam. Opened downstream report against libjpeg-turbo in the meantime, https://bugzilla.redhat.com/show_bug.cgi?id=1164815 Created attachment 89617 [details]
workaround build failures with newer libjpeg-turbo builds
This quick-n-dirty patch is a workaround to libjpeg-turbo not defining some macros anymore. If this approach is agreeable, I can commit or send to reviewboard for feedback. Else, I can continue pushing for libjpeg-turbo devs to restore full compatibility with libjpeg-62 headers/api
This approach is not the best way. Typically, i would not to touch transupp.h, iccjpeg.h because these files are taken as well from 3rd party lib. updating it in the future require to patch again the files and this is a possible stage to forget to do. Also, i think your patch forget other part to patch as jpegutils.cpp for ex, where jpeglib headers are included. I tried to do another way in a cmake macro to check if jpeglib define exist or not with a small compilation process, as it done in this cmake script used to detect jpeglib version : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/cmake/modules/MacroJPEG.cmake Accordingly with define detection, the idea is to use add_definitions() like this for whole compilation : add_definitions("-DJPP(x) x") ... but of course this doesn't work... Gilles PS : no need to use reviewboard, this will duplicates bugzilla workflow (:=))) OK, I'll try to help work on your approach when I get a chance. Created attachment 89620 [details]
patch to MacroJPEG.cmake to check jpeg lib definitions
Rex,
please check and hack this patch please...
Gilles
Rex, Do you take a look to my patch ? Gilles Caulier Looking at it, it's a good start, but: * apparently the compile checks aren't working right * getting cmake's add_definition to accept JPP(x)=x is turning out to be tricky :-/ oh, and will need the defines in more than just digikam/core, kipi-plugins need it too https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Preprocessor-Options.html#Preprocessor-Options seems to imply that -D'JPP(x)=x' should work, but add_definitions(-D'JPP(x)=x') ends up injecting some spaces: -D'JPP ( x ) =x' Boo, and, http://www.cmake.org/cmake/help/v3.0/prop_sf/COMPILE_DEFINITIONS.html looks like can't use COMPILE_DEFINITIONS either , "Function-style definitions are not supported" Good news, looks like we've convinced libjpeg-turbo upstream to fix the breakage on their end, so hopefully workarounds elsewhere (like here) should no longer be needed. See comment from upstream dev , https://bugzilla.redhat.com/show_bug.cgi?id=1164815#c6 Great news. Thanks Rex to report Gilles digikam builds fine with libjpeg-turbo-1.3.90-3.fc22 without workaround. |