The /usr/bin/obs-gamecapture wrapper does a plain LD_PRELOAD, but it assembles the command line by referencing a '$LIB' (originally added in https://github.com/nowrep/obs-vkcapture/pull/56 - I'm not sure what purpose the extra layer of env indirection serves). On Gentoo that var doesn't exist, resulting in a silent failure. I assume it works on the author's distro. Since the ebuild knows at build time where the library is installed, a reasonable fix could be """ sed -i -e 's@\\$LIB@${LIB:-'$(get_libdir)'}@' """. It looks like this never worked in multilib either, I don't think there's a way to autodetect multilib at runtime in a wrapper script. I looked in the apulse ebuild to see what that does and it just installs one wrapper per ABI. People stuck with i686 binaries can do the preload step manually in any case, so it's no big loss. The problem doesn't show up in Vulkan, only OpenGL, because that has its own layers system that obviates the need for LD_PRELOAD entirely.
Well, it should literally add '\$LIB` not just '$LIB'. That's a hack in the dynamic loader to load the library from the correct architecture path. So if you LD_PRELOAD for a 32 bit app, /usr/\$LIB would resolve to /usr/lib, and otherwise it would resolve to /usr/lib64 - or whatever your Gentoo profile sets up as architecture paths. Looking at the linked diff, it adds the path correctly: \$LIB, not $LIB. So it's actually not an env var set by the system, but it's a hint for the dynamic loader which will be resolved by it dynamically. Can you tell me if you're are running a 64 bit system, and which architecture your GL app is? Do you have an example of cmdline which application you're trying to capture? On my system, the ebuild installs both architectures of the GL capture plugin: # qlist obs-vkcapture | grep 'glcapture.so$' /usr/lib/obs_glcapture/libobs_glcapture.so /usr/lib64/obs_glcapture/libobs_glcapture.so It works for me and the GL app is captured in OBS (when running with "bash -x" to enable debug output, you can see that $LIB is literally passed to LD_PRELOAD without resolving, as expected): # bash -x /usr/bin/obs-gamecapture glxgears + '[' 1 -eq 0 ']' + OBS_GLCAPTURE_LIB='/usr/$LIB/obs_glcapture/libobs_glcapture.so' + exec env 'LD_PRELOAD=/usr/$LIB/obs_glcapture/libobs_glcapture.so' OBS_VKCAPTURE=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. [obs-vkcapture] Init GLX 1.5.1 (64bit) [obs-vkcapture] Texture GL_RGBA (Vulkan) 300x300 [obs-vkcapture] Available modifiers: [obs-vkcapture] 0: modifier:216172782120099861 planes:1 [obs-vkcapture] 1: modifier:216172782120099860 planes:1 [obs-vkcapture] 2: modifier:216172782120099859 planes:1 [obs-vkcapture] 3: modifier:216172782120099858 planes:1 [obs-vkcapture] 4: modifier:216172782120099857 planes:1 [obs-vkcapture] 5: modifier:216172782120099856 planes:1 [obs-vkcapture] 6: modifier:0 planes:1 [obs-vkcapture] Got planes 1 fd 47 [obs-vkcapture] Got modifier 216172782120099860 [obs-vkcapture] ------------------ opengl capture started ------------------ Observe that "opengl capture started" is only showing if you are actually using the VK capture source in a running OBS instance. > Since the ebuild knows at build time where the library is installed No, it does not - at least not in the way you think. Because it depends on the architecture of the target application to be captured which version of libobs_glcapture.so needs to be loaded. GL capture works differently to VK capture: The capture lib needs to be injected into the target application (thus it needs to have the same architecture). With VK capture, a VK layer is added which will always run with the native architecture. \$LIB (not $LIB) is a dynamic architecture resolver. I think your problem may be somewhere else, probably inside your OBS setup. Maybe attach a log of your OBS session, too. Thanks. :-D
Another hint: With NVIDIA, obs-vkcapture needs `nvidia-drm fbdev=1 modeset=1` which is not default in Gentoo (see /etc/modprobe.d/nvidia.conf). If you want to use modeset=1, you need to adjust your kernel - see the comment in the configuration file. obs-vkcapture doesn't work without modeset (at least for Vulkan, not sure about OpenGL). If you change these settings, make sure you have a working rescue boot or can ssh into the machine: If kernel and modprobe settings do not properly match, you may probably be booting with a black screen only.
(In reply to Kai Krakow from comment #1) > Looking at the linked diff, it adds the path correctly: \$LIB, not $LIB. So > it's actually not an env var set by the system, but it's a hint for the > dynamic loader which will be resolved by it dynamically. Oof, that invalidates everything I said and thought was correct. I just tested `obs-gamecapture glxgears` and it turns out that works. After some experimenting I think I found the real problem. I've been trying to run minecraft via games-action/prismlauncher. There's a dialog box for a wrapper command and if I give it `obs-glcapture` I can see it work, because it complains in stdout telling me to use gamecapture instead. obs-gamecapture is silent even with OBS_VKCAPTURE_QUIET=0, so although it's running neither of them appear to be doing the LD_PRELOAD correctly. If I set LD_PRELOAD=/usr/lib64/obs_glcapture/libobs_glcapture.so by hand everything works fine. If I give it a different wrapper command like `unshare -f`, I can also see that in the process tree where it should be. The exact command line is about a mile long and I won't paste it here (wc -c = 10028), but it's just calling /opt/(stuff)/bin/java with a long list of switches as far as I can tell. They also have a checkbox to append libMangoHud to LD_PRELOAD, but that works fine... ...UNLESS libobs_glcapture gets loaded last, which the wrapper does when it sees LD_PRELOAD is already set. Setting it manually reverses the order and both things then work. I have no idea why that is. That means it's probably broken for more than just this case though.
Hmm, you may be on something with the loading order... I'm not sure how to setup a test here. Could you please try setting LD_PRELOAD=/usr/\$LIB/obs_glcapture/libobs_glcapture.so manually to verify that nothing in the wrapper script accidentally strips the "\" from the env var? I think you may have either found a bug in the Minecraft wrapper script, or this is a special edge case where loading order is affected. FWIW, Steam itself just LD_PRELOADs both architectures instead of using the \$LIB resolver - maybe for the same reason? It results in games complaining about an incompatible architecture but at least one version gets preloaded. Maybe try with glxgears directly.
(In reply to Kai Krakow from comment #4) > Could you please try setting > LD_PRELOAD=/usr/\$LIB/obs_glcapture/libobs_glcapture.so manually to verify > that nothing in the wrapper script accidentally strips the "\" from the env > var? I've checked, via `strings /proc/$(pidof java)/environ | grep LD_PRELOAD`, that the value that eventually gets set contains the literal prefix '/usr/$LIB/'. That part seems to be functioning correctly. In fact, no matter the order, lsof tells me libobs_glcapture is getting loaded. If I make a copy of the obs-gamecapture script and reverse the order it concatenates things in, the result works too. It seems to be entirely down to the order they hook things in, and I'm inclined to blame mangohud since gamescope+steam has to special case that too.
I'm not sure if we should work around that by patching the wrapper... Reversing the order could mess with other things. We'd need to test this with at least a few GL apps and wrappers - and there are not so many. If this works, we should rather report that upstream and import the patch until it is released. I'll try to do a few tests with mangohud etc using glxgears. So as far as I get from the thread: LD_PRELOAD with libobs_glcapture.so in the front: works. LD_PRELOAD with libobs_glcapture.so as the tail: does not work. But then, this would mean that the "obs-gamecapture" wrapper should always push the preload in the front. If it does that (but it doesn't as far as I can tell), maybe the correct way would be to "mangohud obs-gamecapture %command%" instead of the other way around? The way, obs-gamecapture currently works, the wrapper command should be "obs-gamecapture mangohud %command%", and mangohud should *append* its preload (and it does that if I look at it). So this would be the correct order. What order does prismlauncher do? And does it meddle with the env var internally?
prismlauncher's MangoHud stuff is buried here: https://github.com/PrismLauncher/PrismLauncher/blob/9.2/launcher/minecraft/MinecraftInstance.cpp#L586 So the order is: prismlauncher runs, appends mangohud's libs to LD_PRELOAD (which would usually be unset at this point, coming from a desktop setting), then runs the wrapper script with the environment it just set (effectively doing `mangohud obs-gamecapture %command%`, which I've just tested using glxgears is the non-working combination). I'm honestly not sure where the right place to fix this is so I'll leave that up to you. Good to know there's a way around it at least.
