I run the program "darktable-cltest" and it fails to load the rawdenoise module with the following error: [opencl_synchronization_timeout] synchronization timeout set to 200 0.7834 [iop_load_module] failed to open `rawdenoise': /usr/lib64/darktable/plugins/librawdenoise.so: undefined symbol: _ZGVbM4v_sqrtf I assume this is something in the packging/building Reproducible: Always Steps to Reproduce: 1.run the "darktable-cltest" command 2. 3.
Created attachment 2087556 [details] log of the command run
I wonder if the version of LibRaw changed in fedora 42? LibRaw -> ENABLED - Version 0.22.0-Devel202403 MATH16-16 >> rpm -ql LibRaw-0.21.4-1.fc42.x86_64 /usr/lib/.build-id /usr/lib/.build-id/53 /usr/lib/.build-id/53/648b34b02c4c16fa57142c28b3e64e428895f1 /usr/lib/.build-id/9e /usr/lib/.build-id/9e/972132091cd6e5bd66828a7439c163036d4f26 /usr/lib64/libraw.so.23 /usr/lib64/libraw.so.23.0.0 /usr/lib64/libraw_r.so.23 /usr/lib64/libraw_r.so.23.0.0
(In reply to Mike Hedman from comment #2) > I wonder if the version of LibRaw changed in fedora 42? No, darktable bundles its own static copy of LibRaw (at least it does the way it's built in Fedora). This is more likely because the last build was a while go, and there have been changes around the gcc 15 toolchain since. Most likely a rebuild fixes this?
fwiw. I did download the source rpm and build it yesterday, and it had no effect on the error.
I tried to rebuild but the build failed. Comaintainers, can you please check why the rebuild failed? I am very busy today https://koji.fedoraproject.org/koji/buildinfo?buildID=2706138
The build now fails due to more changes in GCC 15.1 final so dt source needs to be patched (seems to be WIP): https://github.com/darktable-org/darktable/issues/18709 P.S. No need to bump F41 IMHO...
Created attachment 2088600 [details] Cumulative upstream patch for re-enabling build w/ GCC 15
(In reply to Miloš Komarčević from comment #7) > Created attachment 2088600 [details] > Cumulative upstream patch for re-enabling build w/ GCC 15 Thank you. Can you please provide the upstream URL of such patch?
It's a combination of two commits into one actually: https://github.com/darktable-org/darktable/commit/c2be54933a33fff5a5976d460dc298249daaa89a https://github.com/darktable-org/darktable/commit/44884e3f9502e204865b05347ad8b389c20d498a
(In reply to Miloš Komarčević from comment #9) > It's a combination of two commits into one actually: > > https://github.com/darktable-org/darktable/commit/ > c2be54933a33fff5a5976d460dc298249daaa89a > https://github.com/darktable-org/darktable/commit/ > 44884e3f9502e204865b05347ad8b389c20d498a Have you tested a build with such patches? It does not build https://copr.fedorainfracloud.org/coprs/germano/darktable/build/9012931/
> Have you tested a build with such patches? The master dt branch builds, but indeed I haven't tested this backport to the darktable-5.0.x branch, sorry...
Ok, there were more changes to the master than I expected, so the simple backport doesn't work... I'm surprised the patching step didn't fail for you and stopped the build sooner? I'll prepare an updated patch shortly.
Comment on attachment 2088600 [details] Cumulative upstream patch for re-enabling build w/ GCC 15 diff --git a/src/common/colorspaces.h b/src/common/colorspaces.h index c12a0fc6d11c..679d7451aa85 100644 --- a/src/common/colorspaces.h +++ b/src/common/colorspaces.h @@ -22,6 +22,10 @@ #include <lcms2.h> +#ifdef __cplusplus +extern "C" { +#endif + // this was removed from lcms2 in 2.4 #ifndef TYPE_XYZA_FLT #define TYPE_XYZA_FLT (FLOAT_SH(1)|COLORSPACE_SH(PT_XYZ)|EXTRA_SH(1)|CHANNELS_SH(3)|BYTES_SH(4)) @@ -419,6 +423,10 @@ const float whitepoint[2], dt_colormatrix_t RGB_to_XYZ_transposed); +#ifdef __cplusplus +} +#endif + // clang-format off // modelines: These editor modelines have been set for all relevant files by tools/update_modelines.py // vim: shiftwidth=2 expandtab tabstop=2 cindent diff --git a/src/imageio/format/imageio_format_api.h b/src/imageio/format/imageio_format_api.h index 6d7ba2a48e53..aa19d775fed5 100644 --- a/src/imageio/format/imageio_format_api.h +++ b/src/imageio/format/imageio_format_api.h @@ -20,10 +20,6 @@ #ifdef FULL_API_H -#ifdef __cplusplus -extern "C" { -#endif - #include <stddef.h> #include <stdint.h> @@ -33,6 +29,10 @@ #include "common/colorspaces.h" // because forward declaring enums doesn't work in C++ :( +#ifdef __cplusplus +extern "C" { +#endif + /* early definition of modules to do type checking */ #pragma GCC visibility push(default) diff --git a/src/lua/lua.h b/src/lua/lua.h index b4cdb7070..0fe0db59b 100644 --- a/src/lua/lua.h +++ b/src/lua/lua.h @@ -27,6 +27,12 @@ #include "common/dtpthread.h" #include <glib.h> +// while it's poor practice to have includes inside an "extern C" block, we need to +// do this here because the Lua headers don't supply it when compiling under C++.... +#ifdef __cplusplus +extern "C" { +#endif + #ifdef USE_LUA #include <lautoc.h> #include <lauxlib.h> @@ -97,6 +103,10 @@ } dt_lua_state_t; #endif +#ifdef __cplusplus +} +#endif + // clang-format off // modelines: These editor modelines have been set for all relevant files by tools/update_modelines.py // vim: shiftwidth=2 expandtab tabstop=2 cindent
(In reply to Miloš Komarčević from comment #12) > Ok, there were more changes to the master than I expected, so the simple > backport doesn't work... I'm surprised the patching step didn't fail for you > and stopped the build sooner? > > I'll prepare an updated patch shortly. We cannot cherrypick too much stuff from master branch, cause we risk to introduce other bugs just to fix this one which is easily "work-aroundable".
Created attachment 2089162 [details] Cumulative upstream patch for re-enabling build w/ GCC 15 Updated patch for 5.0.x branch
> We cannot cherrypick too much stuff from master branch Up to you. 5.2.x should be arriving in approx. six weeks anyway...
See also bug 2368336 and bug 2373291 NB: upcoming dt 5.2.0 worked around this by forcing non-vectorized version of sqrtf() to be used, but only in librawdenoise.so; there might be other dormant uses of vectorized math functions in other objects (would be great if someone checked using ldd -r).
(In reply to Miloš Komarčević from comment #17) > See also bug 2368336 and bug 2373291 > > NB: upcoming dt 5.2.0 worked around this by forcing non-vectorized version > of sqrtf() to be used, but only in librawdenoise.so; there might be other > dormant uses of vectorized math functions in other objects (would be great > if someone checked using ldd -r). Hello, can you please elaborate about "ldd -r" usage?
> can you please elaborate about "ldd -r" usage? I mean running "ldd -r" on every .so produced by darktable (i.e. in lib64/darktable and below), and checking (grep?) if there are similar _ZGV* symbols for vectorized math functions missing.
Copying from GitHub for completeness here: > $ find /usr/lib64/darktable -type f -name "*.so" -printf "ldd -r %p | grep 'undefined symbol'\n" | sh > undefined symbol: _ZGVbM4v_sqrtf (/usr/lib64/darktable/plugins/librawdenoise.so) > > librawdenoise.so is the only one This symbol is really not present in libmvec.so from glibc-2.41-6.fc42, and neither was it in glibc-2.40-25.fc41... So it looks like it's a GCC 15 bug emitting it?
GCC doesn't make these symbols up, so there must have been something in the source that caused it, probably some declaration with simd attribute or #pragma omp declare simd or [[omp::directive (declare simd)]] attribute etc. And I think glibc doesn't provide those: $ grep sqrt.*__DECL_SIMD_x86_64 /usr/include/{,*/}math* $ grep sqrt /usr/include/finclude/math-vector-fortran.h On which *.o file linked into librawdenoise.so you see the _ZGVbM4v_sqrtf symbol? Can you attach preprocessed source + gcc command line options used to compile that file?
> GCC doesn't make these symbols up, so there must have been something in the source that caused it Indeed it does (and it is now disabled), but this doesn't happen w/ GCC 14 and earlier on F41 even w/ the pragma there?
If there is the pragma or attribute, it doesn't mean the compiler has to use that symbol, only that it can. And it will only if it succeeds to vectorize some loop containing the original call (in this case sqrtf) or spots multiple slp vectorizable calls in scalar code. So, if you declare somewhere __attribute__((simd)) float sqrtf (float); (but why do you do that, glibc does that for functions which it supports in <math.h> already), then float x[1024], y[1024]; void foo (void) { for (int i = 0; i < 1024; ++i) x[i] = sqrtf (y); } or float x[4], y[4]; void bar (void) { x[0] = sqrtf (y[0]); x[1] = sqrtf (y[1]); x[2] = sqrtf (y[2]); x[3] = sqrtf (y[3]); } could be vectorized to use _ZGVbM4v_sqrtf (or might not, it really depends on if it can be replaced by hw instructions fully or partially, what command line options you use etc.
In any case, declare simd or simd attribute is supposed to be used by those providing the definitions of those functions, so if you provide definition of foobarbaz function and it is useful for simd, you can use the pragma or attribute on the declarations as long as you use it also on the definition. So, from this POV https://github.com/darktable-org/darktable/blob/457caec3198277bddac416b7a6d8181bfbd2ff06/src/develop/openmp_maths.h#L26 makes no sense, you don't provide definitions of any of those functions, glibc or some other library does that. And glibc handles it through /usr/include/bits/math-vector.h and /usr/include/finclude/math-vector-fortran.h headers.
Correct, there is #pragma omp declare simd extern float sqrtf(const float x); (not the author here - don't know why and what other platform might supports it?) So, in short - GCC 14 and earlier were not able to vectorize this particular loop containing sqrtf() so we didn't hit this dormant bug, while GCC 15 is. Thanks for the insight!
Note, glibc in particular only defines those as simd a) on specific arches where is libmvec b) for functions which are actually implemented on those arches c) uses _Pragma if -fopenmp or simd attribute for GCC 6+ d) does it only for -ffast-math/-Ofast If the darktable decls are just because you want to use the vectorized versions even in non-ffast-math mode, you really need to track the architectures and glibc versions and exactly what symbols are defined in libmvec and which aren't. Some glibc versions don't have libmvec at all, I think on x86 it is from 2014-ish, on aarch64 from 2023-ish and on other arches not present.
FEDORA-2025-a2b4be7d9b (darktable-5.2.0-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-a2b4be7d9b