digikam 3.5 not compiling with jpeg @9a_0

[jul_bsd@…]

I fully uninstall and reinstall macports yesterday and whereas, initialy, I had a working 3.5.0. after trying to do manual compile of head, it seems some undefined interactions messed up w both install. For this and other reason, I did a reinstall of all macports tree but unexpectedly digikam does not build this time. It stops

:info:build /opt/local/var/macports/build/_Volumes_Data_myports_kde_digikam/digikam/work/digikam-3.5.0/extra/kipi-plugins/common/libkipiplugins/tools/imageio/kpwriteimage.cpp:184:5: error: no matching function for call to 'jpeg_set_quality'
:info:build     jpeg_set_quality(&cinfo, 99, true);
:info:build     ^~~~~~~~~~~~~~~~
:info:build /opt/local/include/jpeglib.h:991:14: note: candidate function not viable: no known conversion from 'bool' to 'boolean' for 3rd argument
:info:build EXTERN(void) jpeg_set_quality JPP((j_compress_ptr cinfo, int quality,
[...]
:info:build /opt/local/var/macports/build/_Volumes_Data_myports_kde_digikam/digikam/work/digikam-3.5.0/extra/kipi-plugins/common/libkipiplugins/tools/imageio/kpwriteimage.cpp:184:5: error: no matching function for call to 'jpeg_set_quality'
:info:build     jpeg_set_quality(&cinfo, 99, true);
:info:build     ^~~~~~~~~~~~~~~~
:info:build /opt/local/include/jpeglib.h:991:14: note: candidate function not viable: no known conversion from 'bool' to 'boolean' for 3rd argument
:info:build EXTERN(void) jpeg_set_quality JPP((j_compress_ptr cinfo, int quality,

jpeg is installed

$ port installed |egrep '(jpeg|jpg)'
  jpeg @9a_0 (active)
  openjpeg15 @1.5.0_1 (active)
$ ls -l /opt/local/include/jpeglib.h 
-rw-r--r--  1 root  admin  49281  2 mar 21:16 /opt/local/include/jpeglib.h
$ ls -l /opt/local/lib/libjpeg.*
-rwxr-xr-x  1 root  admin  211560  2 mar 21:16 /opt/local/lib/libjpeg.9.dylib*
-rw-r--r--  1 root  admin  296472  2 mar 21:16 /opt/local/lib/libjpeg.a
lrwxr-xr-x  1 root  admin      15  2 mar 21:16 /opt/local/lib/libjpeg.dylib@ -> libjpeg.9.dylib

from what I know, on this, there was just an update from jpeg 9_1 to 9a_0 googling didn't show anything related. the compiling command doesn't include "-I/opt/local/include" but lot of other "-I/opt/local/include/{kde,qt,...}", not sure why it doesn't work now . but adding a "configure.env-append CFLAGS="-I${prefix}/include"" doesn't help

[ryandesign (Ryan Carsten Schmidt)]

jpeg @9_0 had a problem with its jpeglib.h which caused build failures for some other ports (see #37984), so in jpeg @9_1 we added a patch to fix that (see r102830). jpeg 9a included a different upstream fix for that problem so I removed our patch and verified that some of the ports we saw problems with before still built ok, but I did not test digikam. Perhaps upstream's fix is still not correct, and I should reinstate the patchfile we were using before. I will need to do some before and after testing.

[jul_bsd@…]

ok. thanks

[ryandesign (Ryan Carsten Schmidt)]

swftools is affected by a similar problem; see #42735.

[ryandesign (Ryan Carsten Schmidt)]

Hopefully fixed in r117626.

[jul_bsd@…]

compile/install well for me. execution still fails but probably another story...

$ /path/to/digikam
[...]
objc[11708]: Class QNSStatusItem is implemented in both /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui_debug and /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined.
[...]
dyld: loaded: /opt/local/lib/kde4/plugins/imageformats/kimg_rgb.so
dyld: loaded: /opt/local/lib/kde4/plugins/imageformats/kimg_tga.so
dyld: loaded: /opt/local/lib/kde4/plugins/imageformats/kimg_webp.so
dyld: loaded: /opt/local/lib/libwebp.5.dylib
QObject::moveToThread: Current thread (0x7fdba8400bb0) is not the object's thread (0x7fdba877b770).
Cannot move to target thread (0x7fdba8400bb0)

On Mac OS X, you might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded. 
dyld: loaded: /opt/local/lib/kde4/plugins/imageformats/kimg_xcf.so
dyld: loaded: /opt/local/lib/kde4/plugins/imageformats/kimg_xview.so
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqgif.dylib
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqico.dylib
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqjpeg.dylib
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqmng.dylib
dyld: loaded: /opt/local/lib/libmng.1.dylib
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqsvg.dylib
dyld: loaded: /opt/local/share/qt4/plugins/imageformats/libqtiff.dylib
digikam(46478)/kdeui (kdelibs): Session bus not found 
To circumvent this problem try the following command (with Linux and bash) 
export $(dbus-launch) 
$ launchctl getenv DBUS_LAUNCHD_SESSION_BUS_SOCKET
[...]
dyld: loaded: /usr/lib/libDiagnosticMessagesClient.dylib
dyld: loaded: /usr/lib/libDiagnosticMessagesClient.dylib
dyld: loaded: /usr/lib/libicucore.A.dylib
dyld: loaded: /usr/lib/libncurses.5.4.dylib
/tmp/launch-SVHto8/unix_domain_listener

and yes, dbus is launched both as messagebus/root and current user, but it seems debug message/dyld loading are messing env

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Hopefully fixed in r117626.

A developer of jpeg says jpeg 9a is correct, and digikam is in error. So in the future I will remove this patch from jpeg, and digikam should be changed instead:

From: Guido Vollbeding <guido@jpegclub.org>
Subject: Re: Build failures with jpeg 9a
Date: March 6, 2014 at 07:07:17 CST
To: Ryan Schmidt <ryandesign@macports.org>

Dear Ryan

Thank you for feedback.

In version 9 we changed to a more reliable definition of the 'boolean'
type (in file jmorecfg.h).
This may cause conflicts with applications which do not comply with the
specified application programming interface (the digikam issue is such
a case).
In other cases, it may be necessary to use the HAVE_BOOLEAN mechanism,
if application insists on using their own type.
We have improved the situation in 9a, but some cases remain which can
only be fixed in application code.

Our suggestion is that software developers be notified to correct or
adapt their programs appropriately.
I have done this with the libjpeg maintainer of the Debian Linux
distribution, in which course we went through a batch of cases which
were affected by the issue, and I offered respective solutions.
Your cases were part of the batch:

digikam:
If "true" is a variable of int type, then using an explicit typecast
"(boolean)true" fixes the issue.
If "true" means a constant of some other bool type, then using TRUE
instead fixes the issue.
The libjpeg API specifies the type "boolean" here with values TRUE
or FALSE, and everything else is an error and always was.

swftools-0.9.2 defines following:

 lib/jpeg.c:

 #ifdef HAVE_JPEGLIB
 #define HAVE_BOOLEAN
 #include <jpeglib.h>

The interpretation of HAVE_BOOLEAN has been changed in new library,
which now means that both the type AND the corresponding values are
defined, which is more general and consistent.
Modifying the place where boolean is defined or changing at this place to

 #ifdef HAVE_JPEGLIB
 #ifndef FALSE            /* in case these macros already exist */
 #define FALSE   0        /* values of boolean */
 #endif
 #ifndef TRUE
 #define TRUE    1
 #endif
 #define HAVE_BOOLEAN
 #include <jpeglib.h>

should make it work with either version of libjpeg.

Any other issues should be variations of these and could be resolved
similarly.  If you have particular problem please let me know and I
will look at it.

Regards
Guido Vollbeding
Organizer Independent JPEG Group

[mkae (Marko Käning)]

Closing this, as we're now at digikam 4.0.0.