| Summary: | digikam-svn fails to compile on Mac OS X | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | rishi.j.sanyal |
| Component: | Portability-Compilation | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ahuggel, carlobaldassi, caulier.gilles, kare.sars, opensourcecat, rishi.j.sanyal, thomas |
| Priority: | NOR | ||
| Version: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fink Packages | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | 1.0.0 | |
| Sentry Crash Report: | |||
|
Description
rishi.j.sanyal
2009-06-09 03:31:22 UTC
About this one : In function ‘UINT64 ByteSwap(UINT64)’: /Users/Rishi/compile/graphics/digikam/digikam/../libs/3rdparty/libpgf/PGFplatform.h:542: error: ‘_byteswap_uint64’ was not declared in this scope This error come from libPGF included internally to digiKam. http://lxr.kde.org/source/extragear/graphics/digikam/libs/3rdparty/libpgf/PGFplatform.h#542 It sound like "_byteswap_uint64" is not declared under MAcOS or a missing system header is not included to this file... Gilles Caulier Kare, I CC you here, because first part of this report is relevant of libksane... Gilles Caulier Rishi, "_byteswap_uint64" is a pure M$ function: http://msdn.microsoft.com/en-us/library/a3140177(VS.80).aspx In libpgf, i this call is now wraaped around compilation directive, for windows. checkout last code from svn and try again Gilles Caulier SVN commit 979228 by cgilles: "-byteswap_uint64" is a pure M$ function. wrap this call for M$ only CCBUGS: 195735 M +2 -0 PGFplatform.h WebSVN link: http://websvn.kde.org/?view=rev&revision=979228 Gilles, Great, thanks so much for the quick fix. As per your instructions, now compiling the latest SVN version allows 'make' to get past 2%, but, now unfortunately fails at 52% with the following error: [ 52%] Building C object digikam/imageplugins/contentawareresizing/CMakeFiles/digikamimageplugin_contentawareresizing.dir/lqr/lqr_rwindow.o /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc1t5g1A.s:81:non-relocatable subtraction expression, "_lqr_carver_read_luma" minus "L00000000001$pb" /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc1t5g1A.s:81:symbol: "_lqr_carver_read_luma" can't be undefined in a subtraction expression /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc1t5g1A.s:62:non-relocatable subtraction expression, "_lqr_carver_read_brightness" minus "L00000000001$pb" /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc1t5g1A.s:62:symbol: "_lqr_carver_read_brightness" can't be undefined in a subtraction expression make[2]: *** [digikam/imageplugins/contentawareresizing/CMakeFiles/digikamimageplugin_contentawareresizing.dir/lqr/lqr_rwindow.o] Error 1 make[1]: *** [digikam/imageplugins/contentawareresizing/CMakeFiles/digikamimageplugin_contentawareresizing.dir/all] Error 2 make: *** [all] Error 2 Any ideas? Has anyone actually successfully compiled digiKam 1.0.0 on a Mac? Anyway, I'm excited that it made it all the way to 52%, as previously 'make' kept on encountering errors at the 1-2% mark... Thanks, Rishi Also, Gilles, interestingly enough, before pgfloader was failing as described in this bug, I was getting the same exact error with qtpgftest: [ 0%] Building CXX object digikam/libs/database/test/CMakeFiles/qtpgftest.dir/qtpgftest.o /Users/Rishi/test/graphics/digikam/libs/database/test/../libpgf/PGFplatform.h: In function ‘UINT64 ByteSwap(UINT64)’: /Users/Rishi/test/graphics/digikam/libs/database/test/../libpgf/PGFplatform.h:542: error: ‘_byteswap_uint64’ was not declared in this scope make[2]: *** [digikam/libs/database/test/CMakeFiles/qtpgftest.dir/qtpgftest.o] Error 1 make[1]: *** [digikam/libs/database/test/CMakeFiles/qtpgftest.dir/all] Error 2 make: *** [all] Error 2 However, a SVN update a week ago or so got rid of that problem, at which time I started getting the pgfloader problem. Anyway, looks like this particular problem is now fixed, but I thought I'd bring it to your attention anyway in case it reminds you of anywhere else this problem might resurface. Cheers, Rishi Now compilation is broken in another 3rd-party library : liblqr. I CC Carlo Baldassi who is developper from lqr team... Gilles Caulier Well, now that I look back at the output of the cmake script, when I run cmake, I see these warnings relevant to liblqr: -- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig -- PKGCONFIG() indicates that lqr-1 is not installed (install the package which contains lqr-1.pc if you want to support this feature) -- Could NOT find Lqr-1 (missing: LQR-1_INCLUDE_DIRS LQR-1_LIBRARIES) A few lines down, it then says: -- liblqr-1 library found.............. NO (optional) I figured since it was listed as 'optional', make shouldn't fail... attempting to install liblqr via MacPorts right now... will let you know if that helps. Rishi Just an update: Now, after installing liblqr-1 0.3.1, cmake gives me the following error: -- Performing Test HAVE_LQR_0_4 -- Performing Test HAVE_LQR_0_4 - Failed -- Could NOT find Lqr-1 (missing: LQR-1_INCLUDE_DIRS LQR-1_LIBRARIES) So, I'll try installing from source to get the latest version... Be right back, Rishi OK, so clearly the bug is with lqr itself, b/c when I try to compile the latest liblqr (0.4.1) from source, it fails & I get the *same exact* error (or so it appears to me) as when I was building digiKam: Making all in lqr if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\""/usr/share/liblqr-1"\" -I.. -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/usr/include -fvisibility="hidden" -g -O2 -Wall -MT lqr_gradient.lo -MD -MP -MF ".deps/lqr_gradient.Tpo" -c -o lqr_gradient.lo lqr_gradient.c; \ then mv -f ".deps/lqr_gradient.Tpo" ".deps/lqr_gradient.Plo"; else rm -f ".deps/lqr_gradient.Tpo"; exit 1; fi libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\"/usr/share/liblqr-1\" -I.. -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/usr/include -fvisibility=hidden -g -O2 -Wall -MT lqr_gradient.lo -MD -MP -MF .deps/lqr_gradient.Tpo -c lqr_gradient.c -fno-common -DPIC -o .libs/lqr_gradient.o if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\""/usr/share/liblqr-1"\" -I.. -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/usr/include -fvisibility="hidden" -g -O2 -Wall -MT lqr_rwindow.lo -MD -MP -MF ".deps/lqr_rwindow.Tpo" -c -o lqr_rwindow.lo lqr_rwindow.c; \ then mv -f ".deps/lqr_rwindow.Tpo" ".deps/lqr_rwindow.Plo"; else rm -f ".deps/lqr_rwindow.Tpo"; exit 1; fi libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\"/usr/share/liblqr-1\" -I.. -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/usr/include -fvisibility=hidden -g -O2 -Wall -MT lqr_rwindow.lo -MD -MP -MF .deps/lqr_rwindow.Tpo -c lqr_rwindow.c -fno-common -DPIC -o .libs/lqr_rwindow.o /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc2iIfJN.s:82:non-relocatable subtraction expression, "_lqr_carver_read_luma" minus "L00000000001$pb" /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc2iIfJN.s:82:symbol: "_lqr_carver_read_luma" can't be undefined in a subtraction expression /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc2iIfJN.s:63:non-relocatable subtraction expression, "_lqr_carver_read_brightness" minus "L00000000001$pb" /var/folders/-H/-Hj0c7j4EKiiSqBDn0C1Xk+++TI/-Tmp-//cc2iIfJN.s:63:symbol: "_lqr_carver_read_brightness" can't be undefined in a subtraction expression make[2]: *** [lqr_rwindow.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Sorry it appears so jumbled here... here are the errors in a .txt file if that makes it easier for you to read: http://staff.washington.edu/rjsanyal/lqr_error.txt Thanks, Rishi Gilles, for now, how do I tell digiKam to compile without Liquid Rescale? Rishi Rishi, You cannot disable liquid rescale for the moment using an option from command line. liblqr is include to digiKam source as 3rd party lib. Cmake try to find an external version, if not, it use internal version. To disable liquid rescale as well, just comment this line : http://lxr.kde.org/source/extragear/graphics/digikam/imageplugins/CMakeLists.txt#52 Gilles Caulier Thanks Gilles. Hopefully a dev from lqr can comment on the failure of lqr to compile on Mac OS X? I disabled liblqr as per your instructions, Gilles, and now make 'makes it' to 70%, at which point it fails on the dngconverter plug-in, yielding the following: [ 70%] Building CXX object kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/__/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.o In file included from /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:11: /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:30:30: error: Multiprocessing.h: No such file or directory /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:197: error: ‘MPCriticalRegionID’ does not name a type /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:204: error: ‘XMP_Mutex’ does not name a type /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:208: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:208: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:209: error: variable or field ‘XMP_TermMutex’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:209: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:209: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:211: error: variable or field ‘XMP_EnterCriticalRegion’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:211: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:211: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:212: error: variable or field ‘XMP_ExitCriticalRegion’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:212: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:212: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:220: error: ISO C++ forbids declaration of ‘XMP_Mutex’ with no type /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:220: error: expected ‘;’ before ‘*’ token /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp: In constructor ‘XMP_AutoMutex::XMP_AutoMutex()’: /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:216: error: class ‘XMP_AutoMutex’ does not have any field named ‘mutex’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:216: error: ‘sXMPCoreLock’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:216: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:216: error: ‘XMP_EnterCriticalRegion’ cannot be used as a function /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp: In destructor ‘XMP_AutoMutex::~XMP_AutoMutex()’: /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:217: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:217: error: ‘XMP_ExitCriticalRegion’ cannot be used as a function /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp: In member function ‘void XMP_AutoMutex::KeepLock()’: /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:218: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp: At global scope: /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:60: error: ‘XMP_Mutex’ does not name a type /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:89: error: redefinition of ‘bool XMP_InitMutex’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:208: error: ‘bool XMP_InitMutex’ previously defined here /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:89: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:89: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:94: error: variable or field ‘XMP_TermMutex’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:94: error: redefinition of ‘int XMP_TermMutex’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:209: error: ‘int XMP_TermMutex’ previously defined here /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:94: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:94: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:98: error: variable or field ‘XMP_EnterCriticalRegion’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:98: error: redefinition of ‘int XMP_EnterCriticalRegion’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:211: error: ‘int XMP_EnterCriticalRegion’ previously defined here /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:98: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:98: error: ‘mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:103: error: variable or field ‘XMP_ExitCriticalRegion’ declared void /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:103: error: redefinition of ‘int XMP_ExitCriticalRegion’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp:212: error: ‘int XMP_ExitCriticalRegion’ previously defined here /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:103: error: ‘XMP_Mutex’ was not declared in this scope /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.cpp:103: error: ‘mutex’ was not declared in this scope make[2]: *** [kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/__/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.o] Error 1 make[1]: *** [kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/all] Error 2 make: *** [all] Error 2 Again, sorry it looks so jumbled here... for easier viewing, I've pasted the errors into a .txt file here: http://staff.washington.edu/rjsanyal/dngconverter_error.txt Now, I checked the relevant CMakeLists.txt file, where it says: # For DNGConverter: XMP SDK need Expat library to compile. # For DNGConverter: DNG SDK need native threads support. I already have Expat installed on my system via MacPorts, and I don't understand what 'need native threads support' means... could you clarify? Could this even be where the problem resides? Anyway, I commented out: # ADD_SUBDIRECTORY(dngconverter) And got digiKam 100% built! Exciting! But... lack of DNG Converter, for me anyway, is a shame, as the DNG converter is one of the features of digiKam I've been using heavily. Anyway we could get the developer on board here too to figure out the problem (unless you have an easy fix)? Thanks, Rishi rishi, I never compile digiKAm and kipi-plugins under MacOSX, because i don't have mac computer (:=)))... But other guy already do it. Look here : http://www.digikam.org/node/418 For DBG problem, i can take a look . This code come from Adobe DNG sdk and must compile fine under Mac. >understand what 'need native threads support' means... could you clarify? Could >this even be where the problem resides? Native Thread want mean POSIX multi-threading support. Linux has pthread lib, Windows has a dedicated one, but under Mac, i don't know... When you run cmake at beginning, is this library is detected or not ? Gilles Caulier rishi, I will be more clear : the compilation error come from XMP sdk from adobe, not DNG sdk, especially here : http://lxr.kde.org/source/extragear/graphics/kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp#30 Sound like "Multiprocessing.h" file is missing on your system. It the Posic thread support lib under MACOS-x. Look here if you can find a solution : http://forum.soft32.com/mac/Multiprocessing-issue-ftopict43400.html Gilles Caulier Thanks Gilles. I changed: #include <Multiprocessing.h> to: #include <CoreServices/CoreServices.h> in the file: kipi-plugins/dngconverter/dngwriter/extra/xmp_sdk/XMPCore/XMPCore_Impl.hpp Now, 'make' proceeds fine through all the xmp_sdk stuff, but then fails with the dng_sdk here: [ 72%] Building CXX object kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/__/dngwriter/extra/dng_sdk/dng_date_time.o /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:64: error: conflicting declaration ‘typedef uint32_t uint32’ /Users/Rishi/compile/graphics/kipi-plugins/dngconverter/dngwriter/extra/dng_sdk/dng_types.h:56: error: ‘uint32’ has a previous declaration as ‘typedef long unsigned int uint32’ make[2]: *** [kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/__/dngwriter/extra/dng_sdk/dng_date_time.o] Error 1 make[1]: *** [kipi-plugins/dngconverter/plugin/CMakeFiles/dngconverter.dir/all] Error 2 make: *** [all] Error 2 Any suggestions there? So close! Many thanks, Rishi Dear Gilles & all other devs here: Gilles, you mentioned that Salvatore had previously compiled digiKam on the Mac; however, that was an exceedingly old version (prior to 0.10.0, I believe)... even 0.10.0 is quite easy to compile on Mac OS X, as long as you follow these instructions: http://www.hyper-world.de/en/2009/04/10/digikam-0100-under-mac-os-x/comment-page-1/#comment-3622 The latest versions of digiKam are hard to compile b/c of all the dependencies. It seems we've pinpointed the problems to just two 3rd party packages: Liquid Rescaling DNG Converter Right now, digiKam SVN is working perfectly on my Mac OS X 10.5.6, as long as the above 2 packages are not included. Let's see if we can get those packages working! As for DNG Converter, after fixing the threading problem with XMPCore, I've isolated the last remaining problem to dng_types.h, line 56. Unfortunately, the most recent dng_sdk from Adobe still has the exact same dng_types.h file, so I'm not sure how to work around this... Hopefully you'll have some input :) Thanks again, Rishi UPDATE: I've added the line: #define _UINT32 to graphics/kipi-plugins/dngconverter/dngwriter/extra/dng_sdk/dng_types.h, as suggested by xbc on http://chdk.setepontos.com/index.php?topic=817.45 2009_03_09. This allows 'make' to proceed up to a whopping 85%, with dngconverter plugin seemingly compiled just fine. However, make fails here, apparently on 'dngvalidate', a part of 'dngconverter': [ 85%] Building CXX object kipi-plugins/dngconverter/test/CMakeFiles/dngvalidate.dir/__/dngwriter/extra/xmp_sdk/XMPCore/ParseRDF.o Linking CXX executable dngvalidate Undefined symbols: "_ConvertFromTextToUnicode", referenced from: Assign_Multibyte(dng_string&, char const*, unsigned long)in dng_string.o "_UpgradeScriptInfoToTextEncoding", referenced from: dng_string::Set_SystemEncoding(char const*)in dng_string.o dng_string::Get_SystemEncoding(dng_memory_data&) const in dng_string.o "_MPEnterCriticalRegion", referenced from: XMP_EnterCriticalRegion(OpaqueMPCriticalRegionID*&) in XMPCore_Impl.o "_ConvertFromUnicodeToText", referenced from: dng_string::Get_SystemEncoding(dng_memory_data&) const in dng_string.o "_CreateTextToUnicodeInfo", referenced from: Assign_Multibyte(dng_string&, char const*, unsigned long)in dng_string.o "_CreateUnicodeToTextInfo", referenced from: dng_string::Get_SystemEncoding(dng_memory_data&) const in dng_string.o "_CreateTextEncoding", referenced from: Assign_Multibyte(dng_string&, char const*, unsigned long)in dng_string.o dng_string::Get_SystemEncoding(dng_memory_data&) const in dng_string.o "_MPDeleteCriticalRegion", referenced from: XMP_TermMutex(OpaqueMPCriticalRegionID*&) in XMPCore_Impl.o "_CFRelease", referenced from: LocalTimeZone(dng_date_time const&) in dng_date_time.o "_CFTimeZoneCopyDefault", referenced from: LocalTimeZone(dng_date_time const&) in dng_date_time.o "_CFTimeZoneGetSecondsFromGMT", referenced from: LocalTimeZone(dng_date_time const&) in dng_date_time.o "_MPExitCriticalRegion", referenced from: XMP_ExitCriticalRegion(OpaqueMPCriticalRegionID*&) in XMPCore_Impl.o "_UCCompareTextDefault", referenced from: dng_string::Compare(dng_string const&) constin dng_string.o "_DisposeTextToUnicodeInfo", referenced from: Assign_Multibyte(dng_string&, char const*, unsigned long)in dng_string.o "_DisposeUnicodeToTextInfo", referenced from: dng_string::Get_SystemEncoding(dng_memory_data&) const in dng_string.o "_CFGregorianDateGetAbsoluteTime", referenced from: LocalTimeZone(dng_date_time const&) in dng_date_time.o "_MPCreateCriticalRegion", referenced from: XMP_InitMutex(OpaqueMPCriticalRegionID**) in XMPCore_Impl.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [kipi-plugins/dngconverter/test/dngvalidate] Error 1 make[1]: *** [kipi-plugins/dngconverter/test/CMakeFiles/dngvalidate.dir/all] Error 2 make: *** [all] Error 2 Again, here is a .txt file of the errors, for easier reading: http://staff.washington.edu/rjsanyal/dngvalidate_error.txt I'm stumped at this point... -Rishi > Hopefully a dev from lqr can comment on the failure of lqr to compile on Mac > OS X? Hi, sorry for the delay, I currently don't have an internet connection at home... The compilation problem for OS X should be fixed in the MacPorts version: http://trac.macports.org/ticket/19685 http://trac.macports.org/changeset/51312 If this works I'll remove those two inlines in the next version (BTW if anyone knows the reason why those inlines break compilation and how to prevent this please let me know...). Carlo Thanks Carlo, but I'm not sure I understand. The latest version on MacPorts seems to be liblqr @1-0.3.1 (I simply did a 'port search lqr') I don't even see a 0.4.x version. Which is why I attempted to download the latest source. But that failed to compile. So what exactly should I do? Thanks, Rishi Gilles, I didn't realize that it was you actually who wrote the dngconverter kipi-plugin? You say on one of the blog posts on the digiKam site (http://www.digikam.org/drupal/node/373#comment-17820) that dngconverter compiles fine on Mac OS X. Have you yourself verified this, or was this an earlier version of dngconverter? Because I can't get around the problems outlined above, even with the modifications I made to dng_types.h and XMCore_Impl.hpp... Cheers, Rishi Rishi, I'm the author of DNGConverter. I have never checked Macos-x compilation. I don't have mac computer. Salvatore has do it : http://www.digikam.org/node/418. I don't know which version he use exactly. I CC him to get more details. Gilles Caulier Gilles, cool. You'll never guess what I use your DNG converter for, but, before I get to that, I just wanted to point out that for some reason (even the Kubuntu Linux version) it doesn't copy over the EXIF data when converting Panasonic LX3 RAW files (.RW2) to DNG, and it messes up the white balance info. So then I'm stuck using exiftool, individually for each file, copy over the EXIF information from the .RW2 file to the .DNG file that DNG Converter made (yes, I can write a script to do this). Even more annoying, though, is that the white balance is so screwed up that even synchronizing white balance info between the .RW2 and the .DNG file *doesn't* work... I have to manually, in Lightroom for example, type in the original Kelvin value recorded in the .RW2 file. I don't know if this is your code or the Adobe DNG SDK... any ideas? Now, just a personal anecdote: I find your DNG converter indispensable for the following reason: Panasonic demanded that RAW converters like ACR perform automatic lens corrections on all RAW files from the LX3 camera. This is because the lens has immense barrel distortion at 24mm. Lens distortion correction can be nice, but it introduces 2 problems: 1.) sometimes it makes people, especially faces, look fat; and 2.) the corners become extremely soft due to the immense geometry correction. Additionally, ACR noise removal is so heavy on LX3 RAW files that there's just too much of an inherent softness to the image (presumably because LX3 is a noisy camera to begin with). With your DNG converter, I'm able to take all the RAW files, convert them to DNG, and for whatever reason, when I import these .dng files into Lightroom, LR no longer does the default corrections... that is, it doesn't apply lens correction nor does it apply noise reduction. This results in more normal looking people (to my eye) and a sharper, albeit noisier, image. But, because it's DNG, I'm able to work on the linear RAW data... that is, I'm able to use ACR's color engine (well, I had to perform a hack for that also, as the color profile that DNG converter packages with the .dng file messed up the name/model of the camera in whatever .dcp profile is included in the DNG file... this makes it such that Lightroom no longer loads the default LX3 profile, but some other profile, presumably whatever rudimentary profile is packaged with the DNG? I don't know why, but you may want to look into this? I fixed this by taking Adobe's default profiles for the LX3 and editing them to reflect the camera/model information that your DNG converter embeds in the DNG conversions from LX3 RAW files). Anyway, what I'm trying to say is, in the end, I can use Lightroom's color profiles with these DNG files, as well as functions like Highlight Recovery, which Lightroom does pretty well. It would be futile to try to do Highlight Recovery on TIFF conversions of LX3 RAW files exported by digiKam (or whatever software), since the highlights would already be compressed due to gamma compression. Obviously I wouldn't be able to apply Adobe's quite pleasing color profiles also if I exported to TIFF. So, here's one big cheer for your DNG converter... hopefully the problems will eventually be fixed :) Finally, Gilles, the errors output when trying to compile DNG converter, as I outlined in 'Comment #18' above -- do they make any sense to you? Cheers, Rishi (in response to Comment #20) > Thanks Carlo, but I'm not sure I understand. > > The latest version on MacPorts seems to be liblqr @1-0.3.1 (I simply did a > 'port search lqr') > > I don't even see a 0.4.x version. Ah ok, I don't have a Mac, and from the website it seemed to me it had been updated. > So what exactly should I do? Just try removing the "inline" directives from lines 48 and 50 of lqr_energy_priv.h, as shown in this patch: http://trac.macports.org/changeset/51312 I hope this works, let me know. Carlo Rishi, Look this entry about DNG white balance: https://bugs.kde.org/show_bug.cgi?id=191907 It's fully relevant of DNG sdk. In fact Adobe sdk and metadata is a mess. It lack of all markernotes where are stored white balance information. So the only solution to this problem is to use default D65. I recommend to use last code from Exiv2 library (svn) where last code to write in DNG file can store original makernotes without to break TIFF/EP structure... Perhaps it can help... I wait also next DNG SDK planed by Adobe. But i'm sure that no improvement will be done in this way. In fact DNG converter from Adobe as private code to restore WB using makernotes. This is wy Adobe sell commercial tools around this format. About your compilation problems under MAcos-x, my experience from this ystem is limited. Without a real computer with this system to hack, it will be difficult to found a way. Sorry. The only words that i can said is: linker, not compiler fail to find symbols with XMP SDK (not DNG sdk)... why ? a missing library ? I don't know... Salvatore, please can help here ? Note : Exiv2 library include also XMP sdk from Adobe, and it compile fine to Mac-OSX. Perhaps Andreas from Exiv2 project can help us here. I CC him... Gilles Caulier (In reply to comment #25) > Note : Exiv2 library include also XMP sdk from Adobe, and it compile fine to > Mac-OSX. > Perhaps Andreas from Exiv2 project can help us here. I CC him... I'm afraid not. All I can say is that in Exiv2 this #if XMP_MacBuild #include <Multiprocessing.h> ... is still there in XMPCore_Impl.hpp and I haven't seen any complains about it. And yes, it has been compiled on Max OS X ( although I also don't have one :) Andreas Hi Andreas, You're absolutely right: the exiv2 source still has the Multiprocessing.h line in the XMPCore_Impl.hpp file, and it compiles just fine (I just tried, even though I have it installed already via MacPorts). Strange. However, the xmpsdk directory in the Exiv2 source package is definitely different from the one included with dngconverter... just take a look at the source directory of xmpsdk & xmp_sdk (yeah, they're even named differently) from Exiv2 and dngconverter, respectively (from left to right) in the following screen capture of the two directories: http://staff.washington.edu/rjsanyal/xmp_sdk.jpg Maybe I'm being naive, but should these xmp_sdk source directories be so different? Thanks, Rishi Hi Rishi,
> but should these xmp_sdk source directories be so different?
I guess they both come from the same source, the original XMP SDK from Adobe. For Exiv2, see doc/README-XMP for some information about how it was derived and differs from the original XMP SDK. Which part they both use of that and how they arrange it may be different.
Andreas
Rishi, In DNGConverter, i have just copied all source code from original Adobe tarball and listed all file to compile into CMakeLists.txt. That all. It compile fine under Linux and , Windows XP/Vista using MinGw and MSVC9 compilers. Adobe said that XMP sdk code is compilable under Macos X... Gilles Caulier +1 for digiKam on OS X. PM to Gilles. Hi Carlo, Perhaps you've already figured this out, but, yes-- removing the "inline" directives from lines 48 & 50 allows for a successful compile of lqr on Mac OS X! I was surprised to see that lqr 0.4.1 was added to MacPorts, and it installs just fine, so I figure that you must've already taken out the "inline" directives before it even went to MacPorts. At any rate, all seems good now with lqr... though I'm still waiting for digiKam to compile through the lqr step (and then, of course, fail on dngconverter, argh!). So now it would seem that dngconverter is the only problem left for a full compilation on Mac OS X! (Although, admittedly, I'm having a little trouble get liblensfun installed on OS X...) Rishi I can now confirm that contentawareresizing plugin compiles just fine with digiKam, & is present in the final build. So, the current status is: for Mac OS X, digiKam only fails to compile at 91% when attempting to 'Link CXX executable dngvalidate'... Rishi Gilles-- Wow, did you change something in the DNG converter code? Because now, on the Mac side of things-- it copies over metadata from Panasonic LX3 .RW2 files to the DNG files when converting to DNG! The White Balance info is still screwed up, but at least aperture, shutter speed, ISO, etc. are all copied over to the DNG file! Or does this have something to do with the Mac side of things? For everyone else-- Gilles fixed some code so that dngconverter now compiles fine on the Mac... so now digiKam compiles 100% on Mac OS X!! We may mark this bug now as 'resolved' :) I was also able to get LensFun to compile to enough of a point that digiKam can add it as a plug-in, and it functions. I'll have to post these instructions somewhere or I will pass them along to LensFun dev in the hopes that he updates it in source. The only thing now is that dngconverter seems to NOT load as a kipi-plugin, so one can't load it from within digiKam, but one can still use the dnconverter application as a standalone. Cheers, & many thanks to all incredible developers out there pushing out such magnificent software :) Best wishes, Rishi |
