Portal 2 engine.so: cannot enable executable stack as shared object requires: Invalid argument

[siroccal]

The game fails to launch due to not being able to load engine.so

failed to dlopen engine.so error=engine.so: cannot enable executable stack as shared object requires: Invalid argument
AppFramework : Unable to load module engine.so!
Unable to load interface VCvarQuery001 from engine.so, requested from EXE.

Other native Linux games and Proton games work fine.
Only Portal and Portal 2 are affected as far as I can tell.
Both Portal and Portal 2 work fine if Proton is used instead of native Linux.

I'm using the normal steam-runtime (not steam-native-runtime).
I've also tried a full reinstall (and deletion of steam folders) of Steam to no avail.

OS: updated Arch Linux with [*-testing] enabled
Kernel: 6.13.0-arch1-2 (64-bit)
Graphics Platform: Wayland
CPU: AMD Ryzen 5 5600
GPU: AMD Radeon RX 6650 XT

ldd -v bin/linux32/engine.so && echo %command%

        linux-gate.so.1 (0xe8ff4000)
        /home/user/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (0xe831b000)
        libtier0.so => not found
        libvstdlib.so => not found
        libsteam_api.so => not found
        libSDL2-2.0.so.0 => /usr/lib32/libSDL2-2.0.so.0 (0xe827e000)
        libm.so.6 => /usr/lib32/libm.so.6 (0xe819a000)
        libdl.so.2 => /usr/lib32/libdl.so.2 (0xe8193000)
        libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xe818e000)
        libuuid.so.1 => /usr/lib32/libuuid.so.1 (0xe8185000)
        /usr/lib/ld-linux.so.2 (0xe8ff6000)
        libc.so.6 => /usr/lib32/libc.so.6 (0xe7f52000)
        librt.so.1 => /usr/lib32/librt.so.1 (0xe7f4d000)
        libGL.so.1 => /usr/lib32/libGL.so.1 (0xe7ee2000)
        libGLdispatch.so.0 => /usr/lib32/libGLdispatch.so.0 (0xe7e66000)
        libGLX.so.0 => /usr/lib32/libGLX.so.0 (0xe7e2b000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xe7cf0000)
        libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xe7cc3000)
        libXau.so.6 => /usr/lib32/libXau.so.6 (0xe7cbc000)
        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xe7cb5000)

/home/user/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /home/user/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=620 -- /home/user/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point --verb=waitforexitandrun -- /home/user/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- /home/user/Games/SteamLibrary/steamapps/common/Portal 2/portal2.sh -game portal2 -steam

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/user/Games/SteamLibrary/steamapps/common/Portal 2/bin/linux32/" ldd bin/linux32/engine.so && echo %command%

        linux-gate.so.1 (0xee4b6000)
        /home/user/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (0xed7dd000)
        libtier0.so => /home/user/Games/SteamLibrary/steamapps/common/Portal 2/bin/linux32/libtier0.so (0xed77d000)
        libvstdlib.so => /home/user/Games/SteamLibrary/steamapps/common/Portal 2/bin/linux32/libvstdlib.so (0xed716000)
        libsteam_api.so => /home/user/Games/SteamLibrary/steamapps/common/Portal 2/bin/linux32/libsteam_api.so (0xed6b9000)
        libSDL2-2.0.so.0 => /usr/lib32/libSDL2-2.0.so.0 (0xed658000)
        libm.so.6 => /usr/lib32/libm.so.6 (0xed574000)
        libdl.so.2 => /usr/lib32/libdl.so.2 (0xed56d000)
        libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xed568000)
        libuuid.so.1 => /usr/lib32/libuuid.so.1 (0xed55f000)
        /usr/lib/ld-linux.so.2 (0xee4b8000)
        libc.so.6 => /usr/lib32/libc.so.6 (0xed32c000)
        librt.so.1 => /usr/lib32/librt.so.1 (0xed327000)
        libGL.so.1 => /usr/lib32/libGL.so.1 (0xed2bc000)
        libGLdispatch.so.0 => /usr/lib32/libGLdispatch.so.0 (0xed240000)
        libGLX.so.0 => /usr/lib32/libGLX.so.0 (0xed205000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xed0ca000)
        libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xed09d000)
        libXau.so.6 => /usr/lib32/libXau.so.6 (0xed096000)
        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xed08f000)

/home/user/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- /home/user/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=620 -- /home/user/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point --verb=waitforexitandrun -- /home/user/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- /home/user/Games/SteamLibrary/steamapps/common/Portal 2/portal2.sh -game portal2 -steam

[smcv]

This sounds like a result of this behaviour change in glibc 2.41:

• dlopen and dlmopen no longer make the stack executable if a shared
  library requires it, either implicitly because of a missing GNU_STACK
  ELF header (and default ABI permission having the executable bit set)
  or explicitly because of the executable bit in GNU_STACK, and the
  stack is not already executable. Instead, loading such objects will
  fail.

—https://lists.gnu.org/archive/html/info-gnu/2025-01/msg00014.html

[smcv]

Probably the same thing as ValveSoftware/Source-1-Games#6978.

[worstperson]

Downgrading glibc does fix it. Alternatively, clearing the executable stack flag also seems to work for this and other affected source games.

cp bin/linux32/engine.so bin/linux32/engine.so.bak
cp bin/linux32/valve_avi.so bin/linux32/valve_avi.so.bak
execstack -c bin/linux32/engine.so
execstack -c bin/linux32/valve_avi.so

[smcv]

The suggestions I mentioned on ValveSoftware/Source-1-Games#6978 would probably be applicable here too (if I understand correctly, Portal 2 isn't exactly the same engine as those games, but is fairly close). I'm not going to duplicate technical details on this issue.

[TTimo]

Portal 2 was updated to fix the issue.

[siroccal]

The update that was pushed to Portal 2 fixes it for me.
But Portal 1 still doesn't work.

[zukas97]

same problem on both hl2 and portal 2 (arch linux)

EDIT: Portal 2 does work now after update

[smcv]

The equivalent issue in HL2 and Portal 1 (and many others) is tracked as ValveSoftware/Source-1-Games#6982, which will be updated when the equivalent issue in each of those games is fixed.

This particular issue tracker only covers Portal 2, so I think this issue can be closed now that Portal 2 has been updated.

[flibitijibibo]

Out of curiosity, was this fixed for Portal 2 by just running stackexec -c or was there a specific change that had to be made to the engine? This affects a number of other libraries so it'd be good to have as much context as possible in case this could be considered a userspace regression in glibc.

[misyltoad]

Just stackexec -c. (for now, future builds bave the linker flag to force it off)

Basically, any use of inline asm can cause your so to be put into the state of not having stack_exec flag AND not having the no_stack_exec flag.

In that situation, glibc just assumes you might need it and says your .so is bad.

glibc has already demonstrated in the past that it does not care about backwards compatibility (see: DT_HASH), so it would not surprise me if they also do not care about this -- despite being an obvious regression for end users.

[flibitijibibo]

We might actually be getting somewhere on the glibc side - they did expect breakages but it sounds very much like the executable bit can be ignored; it doesn't necessarily sound like glibc itself can do it but your information combined with theirs could probably help make an advisory to explain why this happens and how devs can avoid setting it. To be honest this is the first time in 13 years that I've encountered anything remotely like this, so I have to wonder who else has never seen this before. Being able to send something concretely useful to the FMOD team (for example) would help a lot.

glibc thread: https://sourceware.org/bugzilla/show_bug.cgi?id=32653