Darktable windows build help needed

I wanted to restart some test on lightroom.c import module (to import some more metadata: Pull request #1675).
I’ve followed the build.txt document, option A.
Unfortunately the last version of lensfun breaks the process (see redmine bug #12200) for deprecated functions.
Is there a way to use a former version of lensfun ? How ?
Or maybe to avoid lensfun usage ?

Currently Virtualbox is broken in Debian. As soon as I am able to try I will have a look.

Thanks Houz, I’m looking forward to reading you,

I experience the same problem. Find the log attached. build error.txt (21.8 KB)

I think Alexey went ahead too quickly… The current lensfun version in MSYS2 is 0.39.5, which is an alpha version of lensfun, probably should have waited a bit.

Anyhow, you can roll back to an earlier version of a package anytime with:
pacman -U /var/cache/pacman/pkg/packagename-old_version.pkg.tar.xz

And if you want also can set in /etc/pacman.conf to ignore the updates for a specific package

I guess that solves your immediate problem, but on the other side we should also think about how to replace the (to-be) deprecated lensfun calls.

1 Like

Fixing the cmake part is easy, replace version_1 with version_2. But the lens.c part is harder.

Thanks @Peterbud,
The previous lensfun version I’ve found is 0.3.2-4.
After having downloaded it and run the command:
$ pacman -U /var/cache/pacman/pkg/mingw-w64-x86_64-lensfun-0.3.2-4-any.pkg.tar.xz
the first cmake has passed.
But on $ cmake --build . --target install I get this error:

CMake Error at src/cmake_install.cmake:149 (file):
file INSTALL cannot find

I’ll replay the previous cmake(s) and the full procedure if necessary to see if I can find the cause.
About your second suggestion, I’ve to put in pacman.conf:
IgnorePkg =mingw-w64-x86_64-lensfun
Is that correct ?

What you did is correct.

For the specific error with graphicsmagick I have submitted a PR 3 month ago, but has been never merged (I really don’t know why).

You can check and apply it I believe :


Because the relevant part for compiling was committed already.

This sucks. I wanted to do a new dt release this weekend, but having a broken lensfun means that we won’t have a Windows build.

I’ve updated the darktable (with the last merge), overwritten lightroom.c modified and compiled again.
I’ve got a working dt ! :slight_smile: Thanks for your help !
The normal lightroom import features work but I don’t see the effects of my changes yet.
I’ll work on this and probably come back here to get some more support.
I see 2 main difficulties for the time being:

  • where have I to restart the cmake process once I’ve modified the source file (lightroom.c) and maybe avoid to redo everything ?
  • how to make the log work ? At least to see the existing log messages. That would be the best way for me to try to understand what does happen (or not).
    Edit: I see some logs in the log file, but none which could correspond to those in lightroom.c. Is there something like -d lua to activate them ?

When just changing source files you shouldn’t run cmake again. Just call make. That’s the whole point of having a build system.

What do you use in the code for logging? During development I’d just use printf(). In order to see the result you should run darktable from the mingw64 shell you compiled it in. The cmd.exe coming with Windows is crap.

Sorry for this late answer, I’ve been off for a while.

I thought that dt_control_log() was the routine to call and the file C:\Users\[username]\AppData\Local\Microsoft\Windows\INetCache\darktable\darktable-log.txt the place to look at messages.

I’ll make a try with this. Thanks.

Thank you for your support. I’ve been able to test and fix the lightroom.c issues.

For those who start like myself: to see the traces (without leaving dt) I had to add this line:
setvbuf(stdout, NULL, _IONBF, 0);
to avoid buffering.

1 Like
setbuf(stdout, NULL);

may do that as well

Edit: for reference: Do not buffer stdout when rawtherapee.exe is called from msys2 consol… · Beep6581/RawTherapee@eab7483 · GitHub

Some issues to build dt on windows with last msys2 (msys2-x86_64-20180531, I’ve reinstalled it).
To reach the end of builds I had to downgrade lensfun (3.2.4) and graphicmagic (1.3.29).

Once launched dt crashes. I’ve attached the log.

Somewhere in the build I’ve seen something “32 bits detected” … while I’m running windows 10 64 bits. I don’t remember if I had this with the previous environment.

darktable_bt_1ORHQZ.txt (9.1 KB)

Thanks for help !

The windows RT builder, @gaaned92, reported a problem with the latest msys2. Maybe that’s it?

In the log file I see multiple 32 bits components:

Is that correct ? I thought the windows build was 64 bits.
Which mistake could I have made ?

Still trying to make it work… but now I get a build error …

[ 15%] Building C object src/CMakeFiles/lib_darktable.dir/common/collection.c.obj
In file included from C:/msys64/home/Philippe/dt-org/src/common/collection.c:20:
C:/msys64/home/Philippe/dt-org/src/common/collection.c: In function 'dt_collection_shift_image_positions':
C:/msys64/home/Philippe/dt-org/src/common/collection.c:1392:84: error: left shift count >= width of type [-Werror=shift-count-overflow]
   DT_DEBUG_SQLITE3_BIND_INT64(stmt, 3, (image_position & 0xFFFFFFFF00000000) + (1l << 32));
C:/msys64/home/Philippe/dt-org/src/common/debug.h:65:97: note: in definition of macro '__DT_DEBUG_ASSERT__'
     _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wshadow\"") const int x = xin;             \
C:/msys64/home/Philippe/dt-org/src/common/collection.c:1392:3: note: in expansion of macro 'DT_DEBUG_SQLITE3_BIND_INT64'
   DT_DEBUG_SQLITE3_BIND_INT64(stmt, 3, (image_position & 0xFFFFFFFF00000000) + (1l << 32));
cc1.exe: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/lib_darktable.dir/build.make:168: src/CMakeFiles/lib_darktable.dir/common/collection.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1439: src/CMakeFiles/lib_darktable.dir/all] Error 2
make: *** [Makefile:152: all] Error 2


  1. back to commit 0588beb880363f9e0092010ee4f5416217d8f8ef (15th september) this error goes out.
  2. Using image
    (from https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/) instead of the file coming with MSY2 seems to solve the dt crash above.


  1. Issue #12364
  2. Issue #12359

I have Issue #12359 too.