Update g++ version to 12???

Software darktable
1

I’m on Linux Mint 21.1 Vera, and trying to compile the latest release of DT using
./build.sh --prefix /opt/darktable --build-type Release --install –sudo

I get the following error: “GNU C++ compiler version 11.3.0 is too old and is unsupported. Version 12+ is required.”

v 12 is definitely installed and I have fiddled around with the symlinks:
david@Aliks:~/darktable/build$ which gcc
/usr/local/bin/gcc
david@Aliks:~/darktable/build$ which g++
/usr/local/bin/g++
david@Aliks:~/darktable/build$ ls -l /usr/local/bin/g++
lrwxrwxrwx 1 root root 15 Apr 4 09:06 /usr/local/bin/g++ → /usr/bin/g+±12
david@Aliks:~/darktable/build$ ls -l /usr/local/bin/gcc
lrwxrwxrwx 1 root root 15 Apr 4 09:07 /usr/local/bin/gcc → /usr/bin/gcc-12

Probably a lack of understanding on my part - can anyone set me straight?

2

I’m on openSUSE rather than Mint, but hopefully the same thing applies.

Where are the compiler libraries? On my box they are in /usr/lib64/gcc, this has subdirectories for the different gcc/g++ versions.

3

Try

export CC=gcc-12
export CXX=g++-12
./build.sh --prefix /opt/darktable --build-type Release --install --sudo
1 Like
4

On Mint they are in /usr/lib/gcc/x86_64-linux-gnu/

different folders for 11 and 12

5

Fraid that didnt work - same error

6

Might need to also clean out the CMake cache from previous builds? Try to add --clean-build -f to your build command…

export CC=gcc-12
export CXX=g++-12
./build.sh --clean-build -f --prefix /opt/darktable --build-type Release --install --sudo
7

I deleted the darktable folder and started again from scratch - SUCCESS.

looks like these commands did the trick.

export CC=gcc-12
export CXX=g++-12

Thanks all

8

Yep, it was the build cache then… Could’ve saved some trees by not cloning again :wink:

1 Like
9

@Aliks are you building 4.2 or 4.3? The reason I ask is that I am new to the Linux world and I am wonder how hard it is to build the weekly builds of 4.3 or if I should just stick with the flatpack of 4.2.

10

Hi Terry,

Its pretty easy to build the latest dev version (4.3 currently) and there are a couple of advantages:

  1. Compiling on your own machine gives an executable that is noticeably faster. YMMV, but it should be faster than a generic flatpak

  2. You get the latest and greatest modules faster, and bug fixes etc

  3. errr what kind of geek doesn’t build their own . . . OK ignore that - its only an advantage for technical types

Anyway the build instructions on git are pretty good so long as you have some very basic experience with linux and the bash command line. You have to go through the dependencies and install some dev libraries, but that only happens once.
After that you download and compile the base code with the following commands:

git clone --recurse-submodules --depth 1 https://github.com/darktable-org/darktable.git

cd darktable (to go into your newly created git folder)

git config submodule.src/tests/integration.update none

git submodule –init; git submodule update

./build.sh --prefix /opt/darktable --build-type Release --install –sudo

this puts the DT executable into /opt/darktable, from where you can run it with

/opt/darktable/bin/darktable

When you want to upgrade to the next dev weekly build its even easier

Go into your darktable folder, and do a bit of cleanup of old code:

git clean -d -f -x

rm -rf ~/.cache/darktable/cached_kernels*

then download the changes from git and recompile with the following commands:

git pull --rebase
git submodule update
./build.sh --prefix /opt/darktable --build-type Release --install –sudo

The settings for DT are stored in ~/.config/darktable/darktablerc, and these are not affected by upgrades, so any presets etc are preserved.

If you don’t want to mess up your default 4.2 setting, you can segregate your 4.3 dev instance - see the git instructions for details

Ok it all sounds simple to me, but although I am not a programmer, I did start using Linux 40 years ago (Xenix actually) when I was a trainee at IBM. I can understand why it might be a bit more opaque for those more used to Windows and graphical instals.

For Terry - let me know if you need any help

For those moe experienced in DT, please don’t hesitate to correct any errors or suggest improvements in my explanation.

2 Likes
11

@Aliks thanks for your comprehensive reply. I will make time and gives this a go. I am relatively new to Linux and am trying to break away from dependency upon Windows. That is not so easy when they have about 76% of the computer market and we use computers for work. But as I approach retirement it will become practical for me. I now use a linux desktop at home and I have my wife who should be employed as a computer test crash dummy on a linux laptop and she can’t tell the difference from the windows laptop she previously had.

12

To refine a bit on @Aliks’ reply:
Compiling your own version can give you a faster version than any precompiled binary if the build script allows for that (if it’s just set up to compile a version that’s as generic as possible, you won’t get very far).

I’d suggest trying to compile a stable version first, as you know it should compile (after all, it has been done multiple times). And the first time you try to compile a relatively large program you will run into issues. Most often those are dependency issues, where you forgot to install a development version of a required package, or got the wrong version. Not hard to correct, but the error messages can be daunting…

Once you have a compiled version, you should be able to install it next to the pre-compiled version (usually in /opt, instead of /usr), and use either with no problems (as database formats etc. will be the same).
That allows you to see if the speed gain is worthwhile for you, compared to the extra investment in time required by compiling your own binaries.

Using development versions can have some disadvantages: usually less stable, more changes over time, you need to spend more time to keep up, and you may run into e.g. a database change, which means you can’t afterwards use the stable version with your latest edits.

==============
@Terry: It’s not so much the operating system that makes switching to Linux hard, it’s the user software: someone who has to use MS-Office or Adobe software, or particular hardware won’t be happy with Linux. Someone using OpenOffice, darktable, Krita etc. may not even notice the difference…

1 Like
13

My university work place only supports Windows, not even Mac let alone Linux. I plan to walk away from Microsoft, Adobe and numerous scientific widows based software when I retire in 2025. I enjoy trying the Windows insider build each week for DT. Most changes are too subtle to pick up, but some are huge improvements. I am pleased to see in the latest builds that snapshots are renamed according the the module renaming which is helpful to my workflow. I believe that may be thanks to @dterrahe. Much appreciated. The Sigmoid module is growing on for for some shots as well, such as sunsets. Dt is such a fast evolving program. I hope when I retire I can learn some coding or put together educational material for DT to help the project. The best I can do at the moment is be an ambassador for it with my students.

1 Like