Post B0A6wO2NoKIV8azNMu by karolherbst@chaos.social
(DIR) More posts by karolherbst@chaos.social
(DIR) Post #B0A6wLxhWlMchUmbnE by karolherbst@chaos.social
2025-11-11T21:47:05Z
0 likes, 0 repeats
Are there any distributions known for patching out "-static-libstdc++" linker flags from upstream projects?
(DIR) Post #B0A6wN1Havp5ytSz0y by TTimo@mastodon.social
2025-11-11T21:58:17Z
0 likes, 0 repeats
@karolherbst which packages would they patch specifically?
(DIR) Post #B0A6wO2NoKIV8azNMu by karolherbst@chaos.social
2025-11-11T21:59:33Z
0 likes, 0 repeats
@TTimo no clue. I'm just wondering if any distribution will go "nah, we only do shared linking" and that causing bugs that are only fixed by static linking.So I'd kinda know before hand so there are no surprises later
(DIR) Post #B0A6wOowtl95ZDiA4G by TTimo@mastodon.social
2025-11-11T22:27:07Z
0 likes, 0 repeats
@karolherbst using static libstdc++ linking can also break stuff (std::atomic shared between modules). Best distros are the ones that modify upstream the least imo.. (Arch!)
(DIR) Post #B0A6wWuunSfgg2Z2Tg by a1ba@suya.place
2025-11-12T07:17:36.262158Z
0 likes, 0 repeats
@TTimo @karolherbst also passing std::string, which fundamentally changed in C++11...
(DIR) Post #B0A8FQzz7n97mJVum8 by karolherbst@chaos.social
2025-11-12T07:24:58Z
0 likes, 0 repeats
@a1ba @TTimo why is C++ such a pain here...
(DIR) Post #B0A8FZIiG2sdWiKz4q by a1ba@suya.place
2025-11-12T07:32:22.737065Z
0 likes, 0 repeats
@karolherbst @TTimo shared objects on *nix are pain in general.
(DIR) Post #B0A94V7ZYcOhKfPg9Y by karolherbst@chaos.social
2025-11-12T07:34:37Z
0 likes, 0 repeats
@a1ba @TTimo it's all simple if you don't have to care about proprietary apps doing weirdo things, like shipping a shared object that exposes libstdc++ symbols globally 🙃 and you are mesa and kinda have to cope...
(DIR) Post #B0A94dbe0hCneFXo8W by a1ba@suya.place
2025-11-12T07:41:27.521986Z
0 likes, 0 repeats
@karolherbst @TTimo proprietary app could do this with any mesa dependencies and break it in funny ways.remember early steam-runtime days?
(DIR) Post #B0AA5cYTVHx8dF5uqW by karolherbst@chaos.social
2025-11-12T07:42:55Z
0 likes, 0 repeats
@a1ba @TTimo well the biggest reason was there that games shipped with their own libstdc++ and it just got loaded early enough that mesa couldn't deal with it :')Anyway.. it feels like that using a statically linked libstdc++ would just solve all those funny issues...But of course that's going to be _fun_ if you also link to LLVM that still uses a shared libstdc++
(DIR) Post #B0AA5mIBIirSpbY2q0 by a1ba@suya.place
2025-11-12T07:52:16.417866Z
0 likes, 0 repeats
@karolherbst @TTimo yeah, I get it...I wish there was a better way to deal with shared libraries. Not saying it's perfect, but even Windows does a much better job at them.
(DIR) Post #B0AbaSsiDXEOMxUaEC by TTimo@mastodon.social
2025-11-12T12:58:16Z
0 likes, 0 repeats
@a1ba @karolherbst maybe you mean the ABI change, but as far as static linking I'm pretty sure that's ok.
(DIR) Post #B0AbaTusMyYXZxVpEu by a1ba@suya.place
2025-11-12T13:01:06.258699Z
0 likes, 0 repeats
@TTimo @karolherbst yeah. Just don't pass it to others.
(DIR) Post #B0AcaJwBZRhQaHc0Zc by TTimo@mastodon.social
2025-11-12T13:05:46Z
0 likes, 0 repeats
@a1ba @karolherbst one (long term, not likely to happen) solution there would be linker namespaces, which I believe Apple supports. You could link one libstdc++ on one end of the drivers and another in the game without them overlapping.
(DIR) Post #B0AcaLAkykwuPlR9vM by TTimo@mastodon.social
2025-11-12T13:07:36Z
0 likes, 0 repeats
@a1ba @karolherbst you'd still have to take care of matching ABIs if you are going to share objects, but that's reasonable.
(DIR) Post #B0AcaMDH6sYddrcgUK by a1ba@suya.place
2025-11-12T13:12:18.335311Z
0 likes, 0 repeats
@TTimo @karolherbst it's a bit easier if it's plain C types.Though some stuff will break regardless, like aggregate returns.>one (long term, not likely to happen) solution there would be linker namespaces, which I believe Apple supports. You could link one libstdc++ on one end of the drivers and another in the game without them overlapping.in theory, glibc could support this, dlmopen allows creating new link map. But I haven't tried that in practice.
(DIR) Post #B0Aco2EKCfGRigdUrA by a1ba@suya.place
2025-11-12T13:14:50.362671Z
0 likes, 0 repeats
@TTimo @karolherbst >dlmopen allows creating new link mapbut of course that's dlfcn and normal people don't need dlfcn :D
(DIR) Post #B0AhZ1iqJBgBZWZc4e by TTimo@mastodon.social
2025-11-12T14:07:54Z
1 likes, 0 repeats
@a1ba @karolherbst you'd want the dynamic linker to support this obv.
(DIR) Post #B0AztjXysQb4SVW4fI by karolherbst@chaos.social
2025-11-12T15:47:39Z
1 likes, 0 repeats
@a1ba @TTimo because I need it fixed inside mesa, I wonder if glvnd, the vulkan and OpenCL ICD loader could use dlmopen with LM_ID_NEWLM whenever they load a driver.Not sure if that's how dlmopen works exactly here, but they already use dlopen anyway.
(DIR) Post #B0AztkY19mDjYuXcMS by TTimo@mastodon.social
2025-11-12T17:24:31Z
1 likes, 0 repeats
@karolherbst @a1ba let us know how that goes. We can even do some testing for you.We often have problems with this in the steam runtime, where pressure-vessel pulls in the drivers from the host (along with libstdc++), and there's always a collision risk with the titles we are running.We do recommend using static linking of libgcc libstdc++ for games but we can't enforce it, and as pointed out earlier, sometimes it's actually not possible (source2 had that std::atomic problem quite recently).