Arch Linux

Except that it wasn't. What does `type -a digikam` give you?

$ type -a digikam
digikam is /usr/bin/digikam

Should I debug/trace it?

0x00007ffff51b4d22 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff51b4d22 in raise () at /usr/lib/libc.so.6
#1 0x00007ffff519e862 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff53fa802 in __gnu_cxx::__verbose_terminate_handler() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00007ffff5406c8a in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>)
at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#4 0x00007ffff5406cf7 in std::terminate() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#5 0x00007ffff5406f8e in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))
(obj=<optimized out>, tinfo=0x7fffe3f83a48 <typeinfo for google::protobuf::FatalException>, dest=0x7fffe3daa8d0 <google::protobuf::FatalException::~FatalException()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
#6 0x00007fffe3d3f5d1 in () at /usr/lib/libprotobuf.so.30
#7 0x00007fffe3dae789 in google::protobuf::internal::VerifyVersion(int, int, char const*) () at /usr/lib/libprotobuf.so.30
#8 0x00007fff93b0e430 in () at /usr/lib/libtensorflow_framework.so.2
#9 0x00007fff93a45d86 in () at /usr/lib/libtensorflow_framework.so.2
#10 0x00007fff93a45d79 in () at /usr/lib/libtensorflow_framework.so.2
#11 0x00007fff93a45d79 in () at /usr/lib/libtensorflow_framework.so.2
#12 0x00007fff93a45d79 in () at /usr/lib/libtensorflow_framework.so.2
#13 0x00007fff93a45d79 in () at /usr/lib/libtensorflow_framework.so.2
#14 0x00007fff93a464d6 in google::protobuf::internal::InitSCCImpl(google::protobuf::internal::SCCInfoBase*) ()
at /usr/lib/libtensorflow_framework.so.2
#15 0x00007fff93ad2a0d in tensorflow::KernelDef::KernelDef() () at /usr/lib/libtensorflow_framework.so.2
#16 0x00007fff9309d90b in tensorflow::KernelDefBuilder::KernelDefBuilder(char const*) () at /usr/lib/libtensorflow_framework.so.2
#17 0x00007fff93011c7f in () at /usr/lib/libtensorflow_framework.so.2
#18 0x00007ffff7fdce2e in call_init () at /lib64/ld-linux-x86-64.so.2
#19 0x00007ffff7fdcf1c in _dl_init () at /lib64/ld-linux-x86-64.so.2
#20 0x00007ffff7fce0ca in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#21 0x0000000000000001 in ()
#22 0x00007fffffffdaad in ()
#23 0x0000000000000000 in ()
(gdb)

tensorflow is testing system protobuf version which is absurd since they statically link their own protobuf. Not a digikam issue.

Also, no idea what is dlopening tensorflow. Certainly not digikam itself, must be something in the CUDA stack.

Using lddtree I found the solution: libavfilter.so.7 pulled in the tensorflow dependency.

My libavfilter.so.7 comes from ffmpeg-full (AUR) which was compiled locally (a few days ago).

Removing ffmpeg-full for ffmpeg itself and digikam worked.

Sorry for the noise.

I am rather new at arch and don't know what can be done here, but I guess there is nothing but recompiling ffmpeg-full from time to time.

Thanks

This is still an issue that needs fixing in tensorflow IMO, the fact that it's triggered by an AUR package is incidental. Any package that links to both protobuf and tensorflow will crash, since they provide conflicting protobuf symbols. Tensorflow should be compiled against system protobuf, if possible.

Lowering severity as there is no affected official package as far as I can see.

Thanks for your explanation, I completely trust you on that.
Let me know if I can do anything else (testing, compiling, whatever).

We had a similar issue with CUDA last year, where tensorflow had compiled logic to fail when any CUDA component .so version wasn't matching. Their matching check had a bug and didn't work for minor versions. I'll have a look to see if this check is similar and patch it out.

My very old upstream ticket for this: https://github.com/tensorflow/tensorflow/issues/16104