Opened 11 years ago
Closed 10 years ago
#42710 closed defect (worksforme)
digikam 3.5 not compiling with jpeg @9a_0
Reported by: | jul_bsd@… | Owned by: | jgosmann (Jan Gosmann) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.1 |
Keywords: | Cc: | cgilles (HumanDynamo), ryandesign (Ryan Carsten Schmidt) | |
Port: | digikam |
Description
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
Attachments (1)
Change History (9)
Changed 11 years ago by jul_bsd@…
Attachment: | digikam-build-main2.log added |
---|
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
comment:3 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added; ryandesign@… removed |
---|---|
Summary: | digikam 3.5 not compiling → digikam 3.5 not compiling with jpeg @9a_0 |
swftools is affected by a similar problem; see #42735.
comment:4 follow-up: 6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Hopefully fixed in r117626.
comment:5 Changed 11 years ago by 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
comment:6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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
comment:7 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jan@… removed |
---|---|
Owner: | changed from macports-tickets@… to jan@… |
Status: | reopened → new |
comment:8 Changed 10 years ago by mkae (Marko Käning)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Closing this, as we're now at digikam 4.0.0.
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.