00:03 karolherbst: Sooo... did we ever had this issue with games, that have their own private *.so files that ended up exporting libstdc++ symbols? (like std::filesystem stuff) I have the issue that davinci resolve has this situation and clc_helper.cpp code ends up calling into symbols from their private so file (it's even called "libProResRAW.so" so totally not a
00:03 karolherbst: libstdc++ thing) and I wonder if I can do any linker magic to solve this besides statically linking against libstdc++
00:04 HdkR: Welcome to the pain train!
00:15 karolherbst: wait.. isn't this just how C++ functions because of STL?
00:16 HdkR: Of course, but you're not supposed to ship libstdc++.so with your app :P
00:16 HdkR: What is this, flatpak?
00:17 karolherbst: no
00:17 karolherbst: just their "normal" installer
00:17 karolherbst: but don't worry, it's libc++ they ship 🙃
00:18 HdkR: Oh, double the fun
00:18 karolherbst: (and cudart and gstreamer and QT5 and ...)
00:18 karolherbst: maybe I should just enable static linking....
00:18 karolherbst: like...
00:19 karolherbst: sounds like less trouble tbh
00:28 karolherbst: ohh wait we already link libc and libc++ statically.. I guess that just doesn't work properly with rust targets...
00:29 karolherbst: which is weird, because I link the shared lib in a C target...
00:29 karolherbst: ohh that's windows only