Help, please? Error building darktable 2.3.0 from source

Software darktable
1

I just took the Plunge and tried to compile darktable 2.3.0 from source on my Fedora 26 box. The build process apparently stopped when it encountered the following error:

/darktable/src/common/curve_tools.c:108:5: error: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
x = (float *)calloc(n, sizeof(float));

Could somebody please provide me with a bit of guidance to get through this? It’s my first time trying to compile! Thanks in advance

2

there is no such release.
i guess you want to build git master, see GitHub - darktable-org/darktable: darktable is an open source photography workflow application and raw developer
Also, maybe simply use the snapshots @darix’s OBS snapshots

3

Hi @Hevii_Guy,

Remember: to compile something is just nervous the first few times you do it :slight_smile:

I have a clean Fedora 26 on an SSD and I just checked how it would react to building Darktable git master. It worked just fine.

Note: Be sure to have all the build dependencies installed.
You will find them here: https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_22#Fedora-24-and-25
I installed both the Minimal dependencies and the Optional dependencies.

Then I performed the steps outlined here: http://www.darktable.org/install
Go down to git version and follow the instructions verbatim.

Good luck!
Claes in Lund, Sweden

4

Indeed, I want to push my luck to see if I can build 2.3.0 !

I’ve followed the directions as per the links provided but I think that I’m not doing something correctly when trying to install the jsonschema script…

pkg_resources.DistributionNotFound: The ‘jsonschema==2.5.1’ distribution was not found and is required by the application
make[2]: *** [data/CMakeFiles/validate_noiseprofiles_json.dir/build.make:59: data/CMakeFiles/validate_noiseprofiles_json] Error 1

The way that I had attempted this was by entering:

echo "#! /usr/bin/python3

and then pasting:

EASY-INSTALL-ENTRY-SCRIPT: ‘jsonschema==2.5.1’,‘console_scripts’,‘jsonschema’

requires = ‘jsonschema==2.5.1’
import sys
from pkg_resources import load_entry_point

if name == ‘main’:
sys.exit(
load_entry_point(‘jsonschema==2.5.1’, ‘console_scripts’, ‘jsonschema’)()
)" | sudo tee /usr/local/bin/jsonschema

before entering:

sudo chmod +x /usr/local/bin/jsonschema

And, yes, I did manage to install all of the dependencies.

5

Solved the jsonschema issue: The script called for version 2.5.1 yet the current file is 2.6.0. After I had edited the script accordingly, the build finished :grinning:

So now comes another question: How do I start this self-complied version rather than the one installed from the Fedora repositories? Can I have both on my system or must I get rid of the latter?

6

I’ve been googling but clearly, I’ve not been asking the right question. So, I’ll post it here (again):

Prior to compiling 2.3.0., I already had 2.2.5 installed from the Fedora repository. As I had expected (but not wanted), when I enter “darktable” on the command line, the latter version fires up.

My question is:
How can I run the self-compiled 2.3.0 version? I’m certain that this must be quite basic for many of you but, for me it’s new and unfamiliar. Your help would be appreciated!

7

The git version, ie, v2.3, is in /opt/DarkTable/bin/DarkTable (if you followed the instruction)
So, in terminal, type
$ sudo /opt/DarkTable/bin/DarkTable

8

I wouldn’t use sudo to start dt, but rather add your user to a group that can execute the DT binary.

9

@krist please never ever write that again.

1 Like
10

Roman, sorry, will do.

11

Thanks, everybody, for your help. After deleting the “sanctioned” version, I added /opt/darktable/bin/darktable to my path.

Since I’m curious but don’t wish to precariously remain only on the bleedin’ edge, I’ll reinstall darktable from the repositories and then I plan to change the executable name in /opt/… to “darktable23”. Hopefully that will provide me with the best of both worlds!

12

Any specific reason why you arent just using the rpms?

13

Yes. Because I the current rpm is limited to version 2.2.5. I want to live precariously and see what I don’t know how to do with any new developments which are only available on the freshest git version!

14

Read the answer from LebedevRI again and carefully

15

Please be aware that you can’t share a darktable library between different versions. In theory it should gracefully fail (same with XMP files) and just not load the database, but be warned and make backups.

16

Thanks, Houz. At the back of my mind I had a feeling that perhaps I may be treading on thin ice. Your “In theory” qualifier concerns me…

I’ll only run the git versions on one machine. However, since my photo and xmp files reside on a server and thus are also accessed by my production machine, should I be worried about the sidecars being ‘contaminated’ or at worst, ‘damaged’ if opened with the not-ready-for-prime-time version of darktable?

17

Not sure what you are trying to convey, darix.

18

Yes, you should. If the production system uses 2.2.0 or newer then there shouldn’t be any loss of data or corruption, but once the development build touched the picture and wrote the XMP it might have included data that the old dt doesn’t understand and will therefore refuse to load.

19

That he linked to an alternative rpm repository which has up2date rpms for fedora and opensuse for darktable master branch. they are actually rebuild for every git push.