I’ve built a number of versions of 5.9 in the past, using both the automatic and manual ways described in rawpedia; but this time computer says no (see below). Lensfun.h definitely is there, in /usr/include/lensfun and must be there since I just build dt 4.6.1, which requires it. What am I doing wrong?
Screen shot of build error:
It seems you did not install all requirements like lensfun-dev or similar depending on your distribution …
Bearing in mind that the error message explicitly states that there is no such file as lensfun.h, it’s difficult for me to understand how I was able to build darktable 4.6.1 a few days ago, or why Synaptic Package Manager shows me this:
and this:
or this:
Well I’m not really a linux user, but if the source requires <lensfun.h> I dont think that lensfun/lensfun.h is in any way the path expected …
The more I examine this build error the more I am puzzled by it. The early part of the terminal output resulting from running the build script shows:
So lensfun has been found, but then there is a further search:
But why is the build looking in /usr/local/lib? Synaptic tells me that the following lensfun related packages are installed:
If I examine the properties of every one of these packages, I find that not one of them install anything at all in /usr/local/lib - so it is no wonder than the search for library lensfun in this location fails.
Is this an error in the build script ?
Have you tried a clean build? The version of Lensfun found is different from the one shown in Synaptic. Is there another installation lying around? What is the full output of the configure step?
Thanks for finding time to analyse my output.
Firstly, what is a clean build in this context? The outputs shown so far have been obtained by starting with:
On the first attempt: an invocation of the ‘wget’ command shown in Rawpedia right under the heading ‘The Automatic Way’ in the Linux page, under the ‘Compiling RawTherapee’ section.
On subsequent attempts: either by a deletion of the ‘build’ folder within ~/programs/code-rawtherapee, followed by a restart of Mint, and invocation of the build script, or a deletion of the ‘code-rawtherapee’ folder within ~/programs, followed by a restart of Mint and invocation of the build script.
You tell me the version of Lensfun found is different from the one shown in Synaptic. I assume you are referring to the line in the terminal output which says ‘Found lensfun, version 0.3.0.0’ ? This puzzled me too, when compared to Synaptics’ version 0.3.2-6. I have no explanation for it. But I will say that I had a very frustrating time building darktable 4.6.1 a week or so ago (part of the saga is in the darktable category here on Pixls). That frustrating experience was caused by having a copy of lensfun 0.3.95 installed, unknown to me, in /usr/local - but that was all removed (as far as I understand) to allow darktable to build without issue.
Doing a search on the character string ‘lensfun’ across the whole of my system has found no instances of lensfun which appear (to me) to be suspicious. The weakness here of course is that I have no way of knowing what contributes to ‘suspicious’. Any advice on locations that I might check?
The full output you requested follows (apologies for length):
tony@MS-7D15:~$ ./build-rawtherapee
Program name: rawtherapee
Build type: release
Build without updating: false
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 13 (delta 11), reused 13 (delta 11), pack-reused 0
Unpacking objects: 100% (13/13), 1.51 KiB | 36.00 KiB/s, done.
From GitHub - Beep6581/RawTherapee: A powerful cross-platform raw photo processing program
More results that I don’t understand:
Starting at root, running: “find . 02 -maxdepth 20 -type d -iname “lensfun.h””
or
“find . 02 -maxdepth 20 -type f -iname “lensfun.h””
results in:
“find: ‘02’: No such file or directory”
How can this be when the liblensfun-dev package is installed and the file lensfun.h is exactly where Synaptic says it is (in /usr/include/lensfun)?
More importantly, I don’t understand that there is no ‘FindLensFun.cmake’ routine within the Cmake folder in directory ‘Code-RawTherapee’ while there is one in the equivalent folder for a darktable build. Surely cmake needs this routine to be able to find the lensfun library?
You’re asking the find command to search for files in the . and 02 directories and 02 does not exist.
CMake is a build tool and one of the key features is it can find libraries for you. It’s not necessary to have a script to find Lensfun because CMake can do it. darktable probably does extra stuff, like looking for Lensfun in non-standard locations or performing additional checks to see if Lensfun has everything darktable needs. You’ll have to look inside the file if you want to know exactly what it does.
A clean build means deleting the build directory, which is what you have done. I skimmed through one of your threads (this one: Fatal error in build of 4.6.1 - I don't understand how to fix). I suspect there are still some lingering files, directories, and/or configurations from Lensfun 0.3.95 which is causing problems. The documentation for CMake says it uses pkg-config to locate library files. pkg-config gets its data from .pc files that come with library packages. It’s worth a try to search for lensfun.pc files on your computer. This pkg-config guide may indicate where such files are located: Guide to pkg-config
Firstly, it is my practice to explicitly thank people on this forum for spending their valuable time helping to solve problems I have caused for myself, usually through ignorance (with a little synergy from incompetence…). You reply is a powerful example of that assistance so, thank you.
I share your view, and that of others responding to my dt post, about left overs from lensfun 0.3.95. My problem has been in not knowing where to look for them or, indeed, what to look for. Now you have given me somewhere to start. Thank you again.
I’ll update this reply based on the results - for the benefit of others who may stumble into this situation.
Update not quite what I was expecting: see next post
Absolutely it was:
Contents of file explains all the problems I was having. You hit the nail exactly.
I reran the build after completely replacing directory code-rawtherapee. Build failure was not what I was expecting; problem cause seems to be of an order of magnitude more complexity. The un-informed me tends to think this is a bug - but could it be yet another user error?
Terminal output follows:
RT build fail 01Mar24.txt (6.8 KB)
After a system re-start and a new, clean build this appeared at the foot of the terminal output:
There is a warning message at 23% of the way through build (lines 38 to 40) which may be of relevance.
RT build good 01Mar24.txt (93.6 KB)
Update: I meant the word ‘relevance’ to be in the context of being of interest to rt developers, not relevant to the GCC seg fault that I had posted about.
Yes, it is a bug - in your C compiler:
internal compiler error: Segmentation fault
Right at the start of the compilation:
-- The C compiler identification is GNU 12.3.0
-- The CXX compiler identification is GNU 12.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- WARNING: gcc 12.3.0 is known to miscompile RawTherapee when using --ffp-contract=fast, forcing the option to be off
It seems that GCC version has a problem even if the flag is disabled.
See this related thread (same issue, just compiling darktable): Another error compiling darktable from git
Thanks for explaining this and the link to the dt discussion. For the time being, bearing in mind I have a working dt build at 4.6.1 and rt build at 5.10.something, I’m going to take the uninformed cowards route and assume somebody else will fettle the compiler or release a later version.