[BUG]: engine_i486.so: cannot enable executable stack as shared object requires: Invalid argument Unable to load engine, image is corrupt.

[SmileYzn]

👉👈 Contact Details (optional)

https://steamcommunity.com/id/_SmileY

🤔 What happened?

An error while running ReHLDS on arch linux

[eu@pc 27020]$ ./start.sh 
Enabling debug mode
./hlds_run: linha 125: test: unlimited: esperava expressão de número inteiro
gdb: warning: Couldn't determine a path for the index cache directory.
Error: /home/eu/Desktop/27020/engine_i486.so: cannot enable executable stack as shared object requires: Invalid argument
Unable to load engine, image is corrupt.
cat: hlds.9982.pid: Arquivo ou diretório inexistente
                                                    email debug.log to [email protected]
                                                                                              sex 07 fev 2025 22:12:32 -03: Server Quit

Something related with engine_i486.so.

An workaround is call execstack -c engine_i486.so and now ReHLDS works again. But is not the ideal scenario right?

Anyway i hope someone can fix it

⚠️ Meta-information

- No plugins, server can´t run
- No output, server can´t run
   -> Latest ReHLDS master build: https://github.com/rehlds/ReHLDS/actions/runs/12501656147
   -> Latest ReGameDLL_CS master build: https://github.com/rehlds/ReGameDLL_CS/actions/runs/12333552178
- No Plugins!
- Running Arch Linux

📄 Relevant log output

[eu@pc ~]$ fastfetch 
                  -`                     eu@pc
                 .o+`                    -----
                `ooo/                    OS: Arch Linux x86_64
               `+oooo:                   Kernel: Linux 6.13.1-zen1-1-zen
              `+oooooo:                  Uptime: 18 mins
              -+oooooo+:                 Packages: 739 (pacman)
            `/:-:++oooo+:                Shell: bash 5.2.37
           `/++++/+++++++:               Display (Tempest  34'): 3440x1440 @ 144 Hz in 34" [External]
          `/++++++++++++++:              DE: Cinnamon 6.4.6
         `/+++ooooooooooooo/`            WM: Muffin (X11)
        ./ooosssso++osssssso+`           WM Theme: Fluent-Dark (Adwaita)
       .oossssso-`/ossssss+`          Theme: Fluent-Dark [GTK2/3/4]
      -osssssso.      :ssssssso.         Icons: Fluent-dark [GTK2/3/4]
     :osssssss/        osssso+++.        Font: Ubuntu (10pt) [GTK2/3/4]
    /ossssssss/        +ssssooo/-        Cursor: Fluent-dark (24px)
  `/ossssso+/:-        -:/+osssso+-      Terminal: GNOME Terminal 3.54.3
 `+sso+:-`                 `.-/+oso:     Terminal Font: Source Code Pro (10pt)
`++:.                           `-/+/    CPU: Intel(R) Core(TM) i5-7400 (4) @ 3.50 GHz
.`                                 `/    GPU: NVIDIA GeForce GTX 1050 Ti [Discrete]
                                         Memory: 2.83 GiB / 15.56 GiB (18%)
                                         Swap: 0 B / 4.00 GiB (0%)
                                         Disk (/): 26.98 GiB / 438.06 GiB (6%) - ext4
                                         Local IP (enp6s0): 192.168.100.100/24
                                         Locale: pt_BR.UTF-8

                                                                 
                                                                 
[eu@pc ~]$

[anzz1]

Sounds like an issue you should be reporting to Arch Linux maintainers, not here

[SmileYzn]

Did you read the issue correctly? Or do you have any knowledge of Linux??

engine_i486.so has a invalid executable stack section:

Error: /home/eu/Desktop/27020/engine_i486.so: cannot enable executable stack as shared object requires: Invalid argument

I had to mark binary or shared library as not requiring executable stack on library file.

I can't see where is the problem with my or any Linux distribution!

Since any newer / updated Linux distribution will gave you errors with engine_i486, in newer glibc or future versions of glibc!

[anzz1]

Yes if glibc broke ABI compatibility then it is an issue for glibc to fix. glibc has always been backwards-compatible, but it is not forwards compatible so compiling with a newer version of glibc will break compatibility with any older distribution.

Tossing glibc altogether and building with something else like uClibc or musl is something that could be explored though.

[anzz1]

This has been reported a lot elsewhere too e.g. JuliaLang/julia#57250
It seems to have been introduced in glibc-2.41 https://lists.gnu.org/archive/html/info-gnu/2025-01/msg00014.html
In attempt of yet another misguided "security feature" in vein of complicating things instead of just writing good code.
Hopefully they'll stop being idiots and unbreak glibc before it reaches major distros

[SmileYzn]

@anzz1
To be honest glibc developers is not an idiots!

Only the ReHLDS that was compiled with older version of gnu compilser than glibc 2.41 uses.
Still this issue of glibc or arch linux 'idiot' users?

[anzz1]

Well, the analogy about "security" features is that some maintainers today want to force everyone to use training wheels just because there are kids out there who haven't yet learned how to drive a bike

[SmileYzn]

@anzz1

Anyway that developers are not idiots!
There is no arguments that you can use about that to issue related with glibc.

I stop read your posts, because all open source community you call as idiots, review your opinions about developers before post.

And theses comments do not construct any acceptable solution for this issue right?

[anzz1]

Well, the solution is to go through the ReHLDS codebase and check if executable stack is needed for anything (e.g. nested functions) and if not, add a .note.GNU-stack section to the ELF marking stack as not executable.

You missed my point though, which was that I had an issue with maintainers forcing "security" features down people's throats, which ultimately are misguided band-aids lulling people into false sense of security when the only real way to handle security is to write secure code in the first place.
And then they often end up axing functionality (like nested functions in this case), and/or decreasing the speed of code, and causing extra trouble for developers and users alike for little good reason.

But like said, in this case, if nested functions or other stack function trampolines or similar uses aren't used here, yielding to their whims is an option.

Testing compiling without the execstack bit set, there is two options:

1. with gcc use flags -Wa,--noexecstack and -Wl,-z,noexecstack
   or
2. create .S file with this line .section .note.GNU-stack,"",@progbits and link to it while compiling