First off, thanks again to the developers and testers for your continued hard work on darktable!
The darktable 4.2 installation page says that macOS Mojave (10.14) and later are supported. I have an old but still very usable MacBook Pro which cannot be upgraded to Mojave. The last supported release for this laptop is High Sierra (10.13.6). So, a couple of questions:
What is the most recent darktable release which can run on macOS 10.13?
Is it possible for a reasonably skilled software developer to build 4.2 for macOS 10.13? I have a newer Intel Mac which can support up to macOS 12.6.2, and has the most recent Xcode version installed.
Or is the lack of support due to an incompatibility in the OS or its toolchain?
You can try to build following darktable/BUILD.txt at master · darktable-org/darktable · GitHub on your 10.13 machine
Since you’re building just for your system you can ditch the macosx_deployment_target 10.14 line in macports.conf and -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14 in the cmake command.
Hi, I have a Late 2011 iMac that supports High Sierra 10.13.6 and no later.
The latest version of darktable running on it is 3.8.1 (February 2022). For this reason I no longer use darktable.
Thank you Martin. I’d prefer to build on my 8-core Mac Pro running 12.6.2, partly for the extra cores and RAM, partly for the more up-to-date toolchain. But building on the target is an option.
I’ll give it a try. I may have more questions down the road.
I’ve gotten past a few hurdles, and I’m taking notes to document the process for others who want to follow this path. The DT build system thinks the native Xcode clang is too old, so I’ve had to install a newer LLVM and clang via MacPorts, and pass the compilers on the CMake command line. No surprises there. I can’t find any evidence of OpenCL anywhere on this system, but then I don’t think the external GPU on this laptop is beefy enough to bother with it anyway.
[Edit 1] It appears the DT build system treats LensFun as a requirement, even when -DUSE_LENSFUN=OFF is passed to CMake. And I can’t install the MacPorts copy of LensFun, because of a glib2 variant conflict. Any suggestions?
I should probably mention I cloned the release-4.2.0 tag. This is on macOS 10.13.6.
[Edit 2] The glib2 conflict turned out to be of my own making. An older build was installed that I failed to remove before starting the process.
[Edit 3] After removing a few more foot bullets, and ensuring all of the documented prerequisites were in fact installed, I discovered that RAWSPEED_ENABLE_LTO=ON was breaking the rawspeed compiler tests, at least with MacPorts LLVM 15 on macOS 10.13. I turned it off for the time being.
I’ve managed to successfully build and run (briefly) darktable 4.2.0 on my 2011 15" MacBook Pro running macOS 10.13.6 (High Sierra). darktable-cltest even recognized the ancient GPU as OpenCL capable!
I’ve only built it once, in RelWithDebInfo mode. I’m working on reproducible instructions for this process. When I get optimizations working, I would be willing to provide a .dmg for others to use. Until then, here are some breadcrumbs for anyone else foolhardy enough to try this.
The instructions linked above by @MStraeten are mostly complete, but you will trip over issues if you attempt to build on High Sierra or earlier. You will not be able to use Xcode’s clang to build DT.
Uninstall all MacPorts-built shared libraries that DT uses, and any executables that depend on them, before attempting this build. The list in the instructions is not complete, and you will probably trip over older inactive versions of the same libraries.
Beware: if you tell MacPorts to install all the prerequisites and their dependencies from source, it’ll take forever. This is especially annoying because many of the dependencies aren’t part of the final darktable executables, e.g. perl and rust. The Rust compiler took well over an hour to install! I hope to identify the subset of prerequisite dependencies which can be installed prebuilt.
I tried both clang 15 and gcc 12 (both as installed by MacPorts). gcc doesn’t work because it fails to recognize @autoreleasepool, which is apparently an Apple extension to Objective-C, in darktable/src/osx/osx.mm . Therefore you must use clang. I have not yet tried earlier versions of either compiler.
clang’s OpenMP optimizations are, shall we say, suboptimal. You will see many “warning: loop not vectorized” messages. I’ve observed this as well in earlier efforts to build DT on Ubuntu, on a Zen 3 system, so it’s not unique to this obsolete target platform.
With -DRAWSPEED_ENABLE_LTO=ON, the rawspeed build system uses clang compiler/linker arguments that do not work with clang 15 on macOS. The resulting compiler errors cause the CMake configuration process to fail in ugly ways. Building with LTO off works, but is (by definition) suboptimal. I hope to find a solution for this, and report it to the rawspeed team, if it isn’t already fixed in the source.
One issue requires modifying the darktable C source. The C attribute target_clones is accepted by both clang and gcc front ends, but the back ends don’t implement it on 10.13. clang issues a report for a “probable internal compiler bug.” On gcc, the symptom is a compiler error message about the ifunc attribute not being supported. The fix is modifying an #if statement in darktable/src/common/darktable.h so that the __DT_CLONE_TARGETS__ macro is defined as empty. This has performance implications, but they may not be severe for the older CPUs orphaned by newer macOS releases.
I will report back when I have an optimized build to share.
I set it aside for a while. I can’t promise when I’ll get back to it. I still have the Terminal session open, but the laptop it’s on has been asleep for a few weeks.
I also can’t promise that it’ll work on any CPUs older than the Sandy Bridge in my MacBook Pro.
Returning to this old topic: has anyone managed to compile a working, recent(ish) version of darktable, for Mac OS High Sierra?
I have tried to follow the instructions, but I have zero knowledge of programming and gave up after the first couple of failed attempts.
that requires an old macports or homebrew installation - I doubt that there’s someone around having conserved such build environment.
Recent Xcode versions just supports building for 10.14 and later.
