Digikam 0.10.0 under Mac OS X
With the release of Digikam 0.10.0 for KDE4 it is possible to compile Digikam for Mac OS X. There are remaining some minor bugs and, maybe, it does not run as stable as under Linux, but it runs! The steps to compile Digikam for Mac OS X are as follows:
- Install MacPorts. Download and installation instructions can be found at the homepage.
- Open a Terminal.
- Execute sudo port install kdegraphics4 kdeedu4 libusb. "kdeedu4" can be skipped. As far as I know, it provides only the libmarblewidget library which is used by Digikam to display Geotags. The execution of this command may take several hours because the whole KDE4 basis software and libraries have to be downloaded and compiled. However, it is possible to cancel the process by typing Ctrl+C and to continue it with the same command afterwards.
- Execute sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
- Execute sudo launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
- Download libgphoto2 from the homepage. The version which is available by MacPorts is too old for Digikam.
- In a Terminal change into the directory with the downloaded file. Extract it with tar xf libgphoto2-2.4.5.tar.bz2 and change into the newly created directory with cd libgphoto2-2.4.5. (The file and directory name may differ in the version number. In this case you need to adapt them of course.)
- Execute ./configure --prefix=/opt/local The setting of the prefix ensures that the library will be installed in the same path as the other MacPorts programs.
- make
- sudo make install
- Download the Digikam source code.
- In a Terminal change to the directory with the downloaded file. Extract it with tar xf digikam-0.10.0.tar.bz2 and change into the directory with cd digikam-0.10.0.
- Execute cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DQT_QMAKE_EXECUTABLE:FILEPATH=/opt/local/bin/qmake-mac .. The dot at the end of the command should really be there and tells cmake to process the current directory. (The second dot is not part of the command, it ends the sentence.) Again the prefix setting ensures that Digikam will be installed in the MacPorts path. Moreover, the paht to the Qt qmake command is passed manually because otherwise the library wouldn't be found.
- make
- sudo make install
With this Digikam is installed. To start it the following commands have to be executed:
- open /Applications/MacPorts/KDE4/kdeinit4.app
- open /Applications/MacPorts/KDE4/knotify4.app
- open /Applications/MacPorts/KDE4/kded4.app
- open /Applications/KDE4/digikam.app
The best is probably to create a small script, which executes these commands in a row. If you do not start these programs before launching Digikam you won't see any thumbnails or pictures.
To the top
May 21st, 2009 at 06:31
This didn’t quite work for me. It says I’m missing a few libraries. libkipi, libexiv2, libkdcraw.
comments sections certainly aren’t the best way to diagnose issues but I’ll work on compiling these as they are available on the digikam website.
Thanks for pointing me in the right direction!
May 21st, 2009 at 15:04
That’s strange. I think these libraries should be installed with MacPort‘s kdegraphics4 package. In the last days I installed digikam again and added two missing launchctl commands to the tutorial and changed the cmake line for Digikam. But none of these changes have something to do with this libraries.
Maybe these libraries are installed, but the cmake is not able to find them? Then it would help to pass the library paths manually. I’m sure that there is an option for cmake to do that.
If you can solve this problem it would be great to post the solution here. That would help to improve the tutorial further.
May 28th, 2009 at 23:13
digiKam compiled, but it would crash after the first dialog screen where you select the folder for pictures/albums, etc. Actually, it’d get to the splash screen after that, saying ‘Scan Albums’, stay there for a few minutes, then crash.
You’re right that libkipi, libexiv2, and libkdcraw are installed during one of the port installations, as all these now reside in /opt/local/lib
Don’t know what’s going on, but perhaps the following error will be helpful:
When launching “open /Applications/MacPorts/KDE4/kded4.app”, I get the following error:
LSOpenFromURLSpec() failed with error -10810 for the file /Applications/MacPorts/KDE4/kded4.app
Any help would be much appreciated!
Thanks,
Rishi
May 29th, 2009 at 01:15
Nevermind, I restarted my computer and that problem above no longer occurs.
Now, however, digiKam gets thru scanning albums and scanning individual images within all albums, but then hangs on ‘Initializing Main View’.
I ran ./digikam from the terminal to get rid of prior stumbling blocks (it crashed on some images it didn’t like while scanning, so I got rid of those), and now there don’t seem to be any apparent problems… it’s just that the program’s just sitting there on ‘Initializing Main View’.
Any ideas?
Thanks,
Rishi
May 29th, 2009 at 08:37
Sorry, I also have no idea why Digikam hangs when “initializing the Main View”. Apparently Digikam 0.10 has some bugs, especially when you use it with Mac OS.
I also had some images which Digikam did not like. If Digikam does not start it is helpful to start it from a Terminal with the command “/Applications/KDE4/digikam.app/Contents/MacOS/digikam”, because this will print a lot of debug messages and errors to the Terminal.
June 9th, 2009 at 00:44
Thanks for the reply. I got it past the ‘Initializing Main View’ by, surprisingly, attempting to quit the program (right-click the program in the dock –> ‘Quit’… not ‘Force Quit’). Instead of quitting, the main window came up!
This reproducibly works.
However, unsatisfied with version 0.10.0, I attempted to compile the most recent SVN versions. This required a little more work, like installing ‘SANE’ & ‘SANE backends’. kdegraphics compiles and installs fine, but when I try to get ‘digikam’ & ‘kipi-plugins’ to compile, all fails. The cmake script executes without an ‘errors’ per se, but gives me tons of the following warnings:
“CMake Warning at /opt/local/share/apps/cmake/modules/KDE4Macros.cmake:561 (add_library):
Cannot generate a safe linker search path for target kipiplugin_sendimages
because files in some directories may conflict with libraries in implicit
directories:
link library [libkipi.dylib] in /usr/lib may be hidden by files in:
/opt/local/lib
link library [libkexiv2.dylib] in /usr/lib may be hidden by files in:
/opt/local/lib
link library [libkdcraw.dylib] in /usr/lib may be hidden by files in:
/opt/local/lib
Some of these libraries may not be found correctly.”
Next, when I invoke ‘make’, I get errors pretty early on, that look something like this:
[ 0%] Built target digikam-svnversion
[ 0%] Building CXX object digikam/digikam/CMakeFiles/digikamcore.dir/__/libs/dimg/loaders/pgfloader.o
/Users/Rishi/compile/graphics/digikam/digikam/../libs/3rdparty/libpgf/PGFplatform.h: 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
make[2]: *** [digikam/digikam/CMakeFiles/digikamcore.dir/__/libs/dimg/loaders/pgfloader.o] Error 1
make[1]: *** [digikam/digikam/CMakeFiles/digikamcore.dir/all] Error 2
make: *** [all] Error 2
I have a feeling this has to do with those cmake errors I alluded to above… which themselves probably (I think?) have to do with some packages being installed (by Macports) under /opt/local vs others in /usr? Do you think this is the problem and, if so, how do you get MacPorts to install to /usr instead of /opt/local?
This particular SVN version compiles fine under Kubuntu 9.04 which I have running under Parallels… I just wouldn’t mind getting it to work on Mac OS X. ‘RC 1.0.0′ has 100 times as many features as 0.10.0
Any input would be most welcome… additionally, thanks for posting this entire post to begin with! I need to get a blog going stat.
Rishi
June 9th, 2009 at 13:29
The first problem is, that there are some libraries installed in /usr/lib AND in /opt/local/lib. Therefore the cmake program does not know which versions of the libraries to use and may chose the wrong version. There may be command line parameters to tell cmake which directory contains the correct versions, but I’m not sure (you would have to google this).
But I suggest to uninstall the corresponding Macports packages to prevent these version conflicts.
I’m not sure whether these version conflicts result into the make errors. However, I do not know what else these could cause.
AFAIK there is no possibility to change the MacPorts install directory (but I may be wrong). Even if there would this possibility I wouldn’t do this. It’s better to keep MacPorts and the rest of OS X separated.
Maybe I will try to compile the svn version myself, when I have a little bit time to do this.
June 15th, 2009 at 21:39
Hi,
As for that last uint64 problem, Gilles, the dev of digiKam, fixed something in the code that was calling for a Windows function on a Mac platform.
In fact, everything’s now fixed except for 2 third-party plugins.
Apparently, it’d seem that there aren’t many of us that have successfully compiled the SVN version of digiKam… the devs themselves haven’t even tried.
I finally successfully compiled the SVN version *without* Liquid Rescale (lqr) and *without* dngconverter, using your instructions here along with a number of other installations/modifications.
If you’d like to, join our discussion here with the developers of digiKam & LQR & a couple other people:
https://bugs.kde.org/show_bug.cgi?id=195735
I think together we could figure out once & for all how to get this done on the Mac…
Cheers,
Rishi
June 16th, 2009 at 15:51
My time for messing around with compilation problems is very limited at the moment. However I might try to compile the SVN version soon. I already looked over the discussion at bugs.kde.org and will join eventually if I discover anything useful.
- Jan
June 17th, 2009 at 21:41
Hi Jan,
As of today, the SVN version of digiKam compiles 100% on the Mac (Gilles fixed dngconverter to compile on Mac, but I dunno if he’s updated the SVN version yet), and Liquid Rescale has also been fixed in MacPorts. The only plugin that doesn’t work yet is LensFun– I’ve contacted the developer and he might be willing to work with me on getting LensFun to fully compile on the Mac. So… things are looking good.
Quick question for you… you mention to run:
1. open /Applications/MacPorts/KDE4/kdeinit4.app
2. open /Applications/MacPorts/KDE4/knotify4.app
3. open /Applications/MacPorts/KDE4/kded4.app
4. open /Applications/KDE4/digikam.app
I see that kdeinit4.app is needed to read thru the directory structure on my hard drive when, e.g., selecting a directory for my images in digiKam (without it, digiKam can’t read any of my directories), but digiKam seems to run fine without knotify4.app & kded4.app… what are these for and are they necessary?
Thanks,
Rishi
June 18th, 2009 at 08:30
That are great news!
Concerning your question: Sadly, I do not know exactly what the first three programs do. But when I compiled Digikam I had to launch knotify4.app and kded4.app before launching digikam.app. Otherwise no thumbnails showed up. Maybe something changed in the Digikam oder kdeinit4.app code, so that those two programs are not necessary any longer. I would say, if as long as it works for you without knotify4.app/kded4.app do not start them. However, there is surely no harm in starting these programs.
I have updated the KDE packages with MacPorts some day ago and this broke my own Digikam installation. Therefore I will soon recompile it from SVN.
- Jan
June 21st, 2009 at 22:22
Jan, by the way: you mention above that gphoto2 must be compiled from source (2.4.5), not from MacPorts b/c MacPorts only has the older version (2.4.4).
But gphoto2 mentions that there were only minor updates between 2.4.4 and 2.4.5. Do you know for a fact that digiKam *doesn’t* work with gphoto 2.4.4?
Thanks!
Rishi
June 21st, 2009 at 23:38
No, I don’t know this for fact. The Macports version may have been updated since I wrote the tutorial. In fact this is very probable, because I have installed version 2.4.4. Therefore it should be possible to use the Macports version, now.
Tonight I’ll try to compile the SVN version (after I resolved all dependencies last week, but some optional libraries).
gn, Jan
July 31st, 2009 at 04:30
FYI, digiKam SVN won’t compile unless you’re using 4.2.0 versions of all KDE stuff (kdelibs, etc.). Since MacPorts as updated all KDE stuff to 4.2.4, you’re screwed unless you haven’t updated MacPorts. Luckily I have an older installation of OS X that has an older MacPorts installed… so I could get 4.2.0 versions installed… of course, if I ever now run ‘sudo port -d selfupdate’, I’ll be screwed, as all KDE stuff will be upgraded to 4.2.4 & digiKam will crash.
Sad. But I don’t know what’s broken in 4.2.4 so have no clue as to where to even begin addressing this problem…
Rishi
July 31st, 2009 at 04:31
P.S. Compiling the SVN version is totally worth it tho. With tools such as dngconverter, automatic lens corrections, choise of RAW demosaicing algorithms, content-aware resizing, etc…. it’s really quite the software package!
-Rishi
July 31st, 2009 at 08:55
I was able to compile Digikam 0.10.0 as well as the digikam-1.0.0-beta2 version with KDE 4.2.4_0+darwin_9.
Digikam 0.10.0 works, except that it crashes when I delete albums.
Digikam 1.0.0 Beta 2 crashes directly after startup.
But I just saw, what you problem may be: Older KDE versions in MacPorts used qt-kde, but the newest uses qt-mac. Therefore the correct cmake command is NOT:
cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DQT_QMAKE_EXECUTABLE:FILEPATH=/opt/local/bin/qmake-kde .BUT:
cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DQT_QMAKE_EXECUTABLE:FILEPATH=/opt/local/bin/qmake-mac .I have already changed it above.
July 31st, 2009 at 13:13
I just compiled the SVN version of Digikam with KDE 4.2.4 without any problems and it also seems to run without problems. But I did not compile the kipi-plugins, therefore these are currently missing. I have to see whether I get them compiled, too. There seemed to be problems, because cmake could not find ksane or so.
If I get the whole SVN version running, I will think about writing an updated Howto for this version. Maybe I will even look into the port file format and create a port for macports. But I do not promise anything.
August 18th, 2009 at 13:10
Another success story here, followed the instructions exactly, except I had to disable libusb (don’t really need it because my mbp has a card reader) in libghoto2 compilation with –with-libusb=no because of some library version mismatch. Used app/library versions were digigam 0.10.0 & libgphoto2-2.4.6 and haven’t had any problems/crashed yet.