Simon McVittie

@alkazar: The Steam Linux Runtime (SLR) and Proton are designed to be used in conjunction with Steam, with one copy of each major version of SLR and one copy of...

> I'm not sure it's particularly good or intentional that the internal usage of std::regex in a Vulkan layer pulled from the host by pressure-vessel ends up calling into libengine.so...

One possible mitigation for this would be having Vulkan-Loader load its layers with `RTLD_LOCAL` if it doesn't already, and having the Source engine similarly load its internal libraries `libengine.so`, etc....

> having the layer statically link against libstdc++ seems to avoid the problem Yeah, that's a useful workaround if you can arrange for it to happen on the host system....

> The loader is using `RTLD_LAZY | RTLD_LOCAL` That means the Vulkan layer can't cause the equivalent of this crash in Source2 engine code, but the Source2 engine can still...

> When using local builds of this layer AND enabling with vkconfig I get std::bad_cast. This also happens when using the Vulkan-ValidationLayer. > > Local builds of both of the...

OK, vkconfig is available in Arch (packaged in `vulkan-extra-tools`), so I can experiment with it without installing software from outside the distro. It looks as though it arranges for extra...

> Does the runtime do something special for layers set in the VK_INSTANCE_LAYERS environment variable? No, the source code doesn't even mention it. At the moment we "capture" every implicit...

I tried to reproduce this on an up-to-date Ubuntu 24.04 Nvidia system with the distro's validation layer (version 1.3.275.0-1), by creating this: ``` $ cat ~/.local/share/vulkan/implicit_layer.d/SteamRuntimeIssue694.json { "file_format_version": "1.1.2", "layer":...

> having the layer statically link against libstdc++ seems to avoid the problem I created a simplified version of this situation to test various ideas against, and I found that...