libretro
[Linux x86-64] gpSP core fails to load - can't be launched because the executable stack flag is set on Linux with SELinux security policies
Is there an existing issue for this?
- [x] This is a bug in RetroArch frontend
- [x] I have searched the existing issues
Description
When opening the gpSP core, the core fails to load and the -v log shows the following error:
gpsp_libretro.so: cannot enable executable stack as shared object requires: Invalid argument
This happens in version ab3b175848 in EndeavourOS and b2ceb50 in Ubuntu. The earlier Flatpak version 864ad02177 from Jan 10 2025 loads the core correctly. The current nightly build of gpSP is the same across all 3 systems and appears to be a problem with Retroarch itself.
Expected behavior
The gpSP core should load and play GBA games normally
Steps to reproduce the bug
Start the latest version of Retroarch with the -v switch install the gpSP core Attempt to start the gpSP core either through starting a GBA game or the Load Core menu (doesn't matter which) The core will fail to load and place the above error message in the log
Version/Commit
1.20.0 ab3b175848
Bisect Results
864ad02177
Present in the nightly version
I don't know
Platform & operating system
Linux x86-64
Affected Cores
gpSP 1.0.0-b0d5d27
Environment information
Installed via Pacman/AUR (Endeavour) and APT (Ubuntu)
Relevant log output
[retroplex@RetroPlex ~]$ retroarch -v
[INFO] [Config]: Looking for config in: "/home/retroplex/.config/retroarch/retroarch.cfg".
[INFO] RetroArch 1.20.0 (Git ab3b175848)
[INFO] === Build =======================================
[INFO] CPU Model Name: AMD Ryzen 5 PRO 3400G with Radeon Vega Graphics
[INFO] Capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 SSE4 SSE42 AES AVX AVX2
[INFO] Version: 1.20.0
[INFO] Git: ab3b175848
[INFO] Built: Apr 21 2025
[INFO] =================================================
[INFO] [Input]: Found input driver: "x".
[INFO] Cannot resolve save file path.
[INFO] Cannot resolve save state file path.
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Core]: Geometry: 320x240, Aspect: 1.333, FPS: 60.00, Sample rate: 48000.00 Hz.
[INFO] [Video]: Set video size to: fullscreen.
[INFO] [Video]: Starting threaded video driver..
[INFO] [Wayland]: Registered interface wl_compositor at version 6
[INFO] [Wayland]: Registered interface zxdg_decoration_manager_v1 at version 1
[INFO] [Wayland]: Registered interface wp_viewporter at version 1
[INFO] [Wayland]: Registered interface wp_fractional_scale_manager_v1 at version 1
[INFO] [Wayland]: Registered interface wl_shm at version 1
[INFO] [Wayland]: Registered interface wl_seat at version 9
[INFO] [Wayland]: Registered interface zwp_pointer_constraints_v1 at version 1
[INFO] [Wayland]: Registered interface zwp_relative_pointer_manager_v1 at version 1
[INFO] [Wayland]: Registered interface wl_data_device_manager at version 3
[INFO] [Wayland]: Registered interface wp_cursor_shape_manager_v1 at version 1
[INFO] [Wayland]: Registered interface zwp_idle_inhibit_manager_v1 at version 1
[INFO] [Wayland]: Registered interface wp_content_type_manager_v1 at version 1
[INFO] [Wayland]: Registered interface xdg_wm_base at version 6
[INFO] [Wayland]: Registered interface wl_output at version 4
[INFO] [Wayland]: Compositor doesn't support the wp_single_pixel_buffer_manager_v1 protocol!
[INFO] [Vulkan]: Vulkan dynamic library loaded.
[INFO] [Vulkan]: Found vulkan context: "vk_wayland".
[INFO] [Vulkan]: Detecting screen resolution: 1920x1080.
[INFO] [Vulkan]: Found GPU at index 0: "AMD Radeon Vega 11 Graphics (RADV RAVEN)".
[INFO] [Vulkan]: Using GPU index 0.
[INFO] [Vulkan]: Using semaphores for WSI acquire.
[INFO] [Vulkan]: Using GPU: "AMD Radeon Vega 11 Graphics (RADV RAVEN)".
[INFO] [Vulkan]: Queue family 0 supports 1 sub-queues.
[INFO] [Vulkan]: Got 3 swapchain images.
[INFO] [Wayland] Failed to specify monitor for fullscreen, letting compositor decide
[INFO] [Vulkan]: Using resolution 1920x1080.
[INFO] [Vulkan]: Using RGB565 format.
[INFO] [Vulkan]: Loading stock shader.
[INFO] [udev]: Pad #0 (/dev/input/event15) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event15) supports 16 force feedback effects.
[INFO] [Autoconf]: Xbox 360 Controller configured in port 1.
[INFO] [Joypad]: Found joypad driver: "udev".
[INFO] [Video]: Found display server: "null".
[INFO] [Audio]: Set audio input rate to: 48000.00 Hz.
[INFO] [PulseAudio]: Requested 24576 bytes buffer, got 18432.
[INFO] [Audio]: Started synchronous audio driver.
[INFO] [ALSA] Using ALSA version 1.2.14
[INFO] [Microphone]: Initialized microphone driver.
[INFO] [Display]: Found display driver: "vulkan".
[INFO] [Playlist]: Loading history file: "/home/retroplex/.config/retroarch/content_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/retroplex/.config/retroarch/content_music_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/retroplex/.config/retroarch/content_video_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/retroplex/.config/retroarch/content_image_history.lpl".
[INFO] [Playlist]: Loading favorites file: "/home/retroplex/.config/retroarch/content_favorites.lpl".
[ERROR] Failed to open libretro core: "/home/retroplex/.config/retroarch/cores/gpsp_libretro.so"
[ERROR] Error(s): /home/retroplex/.config/retroarch/cores/gpsp_libretro.so: cannot enable executable stack as shared object requires: Invalid argument
[INFO] [Config]: Saved new config to "/home/retroplex/.config/retroarch/retroarch.cfg".
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..
[INFO] Threaded video stats: Frames pushed: 3649, Frames dropped: 0.
Hmm, I can't reproduce here (ubuntu 64-bit) using a recent build of RetroArch (4/17, git hash c14016d6a2) and the latest gpSP-libretro from the online updater.
Hmm, I can't reproduce here (ubuntu 64-bit) using a recent build of RetroArch (4/17, git hash c14016d) and the latest gpSP-libretro from the online updater.
That's weird, my current build on EndeavourOS is from 4/21 and gives that error message on two separate machines. Update: Installed the latest retroarch-git from AUR (ab515cd22d), still got the same error.
hmm, I just self-compiled latest git and still no problems here. I obviously believe you that it's not working on your end, but we'll have to figure out what's different :/
The versions I'm using have mostly been from the package manager. I have no clue why that makes a difference, but that core just refuses to load on anything but the flatpak version on my PC and laptop. Both are AMD based if that makes any difference?
On Tue, Apr 22, 2025, 10:13 PM hizzlekizzle @.***> wrote:
hmm, I just self-compiled latest git and still no problems here. I obviously believe you that it's not working on your end, but we'll have to figure out what's different :/
— Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/17825#issuecomment-2822949012, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAC2VUHRBLCUYEIXMKN4MD224AM5AVCNFSM6AAAAAB3U6DPIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRSHE2DSMBRGI . You are receiving this because you authored the thread.Message ID: @.***> hizzlekizzle left a comment (libretro/RetroArch#17825) https://github.com/libretro/RetroArch/issues/17825#issuecomment-2822949012
hmm, I just self-compiled latest git and still no problems here. I obviously believe you that it's not working on your end, but we'll have to figure out what's different :/
— Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/17825#issuecomment-2822949012, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAC2VUHRBLCUYEIXMKN4MD224AM5AVCNFSM6AAAAAB3U6DPIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRSHE2DSMBRGI . You are receiving this because you authored the thread.Message ID: @.***>
This one was a surprise to me, but the same error pops up on 1.19.1 on OpenSUSE, installed from package manager.
I also tried Fedora 42 but there's some dependency issue preventing install.
The error points to SELinux settings. Can you check with ls -lZ , how the RetroArch executable looks like? It may be possible to work around with chcon.
Can't reproduce on an EndeavourOS install I just made, to a Raspberry Pi 4 (although that platform does not seem to carry the gpsp core in the repository, so I got it from elsewhere).
Is it specific to gPSP? Can other cores be loaded?
I haven't tried every core out there, but yes, gPSP is the only one that fails to load.
It seems to be specific to Linux x86-64 and the Ubuntu/Arch/AUR Git packages, maybe other distros I haven't tested, but not the Flatpak version.
The error is still happening in 1.21 in the AUR retroarch-git package.
I believe I can confirm that the buildbot is doing something wonky... because, as I imagine, the server lives on a device that runs SELinux!?
I grabbed the latest gpSP nightly but got the relevant error.
I compiled it myself (curl+unzip+cd+make) and got no such error.
Not to become a meme, but I'm also on Arch. To be clear though, I do not run SELinux on the test device.
Indeed, using this tool execstack, the executable stack flag is set for gpsp_libretro.so.zip
execstack -q gpsp_libretro.so
X gpsp_libretro.so
For a workaround, you can clear it using
execstack -c gpsp_libretro.so
@kc32 Can you rename the issue title to something gpSP core can't be launched because the executable stack flag is set on Linux with SELinux security policies.
P.S = I can't reproduce the issue with self build.
Indeed, using this tool execstack, the executable stack flag is set for gpsp_libretro.so.zip
execstack -q gpsp_libretro.so X gpsp_libretro.soFor a workaround, you can clear it using
execstack -c gpsp_libretro.so@kc32 Can you rename the issue title to something gpSP core can't be launched because the executable stack flag is set on Linux with SELinux security policies.
P.S = I can't reproduce the issue with self build.
Sure enough, that was it. Title updated.
I also checked my entire cores folder with execstack and it looks like the MelonDS core has the same flag, and also won't load until cleared with execstack -c
Looking at this, execstack is assumed to be true if there is no PT_GNU_STACK in .eh_frame_hdr (see https://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/progheader.html) indicated by the magic 0x6474e551. You can use readelf to look at the GNU_STACK program header. Looking at the shared library, the GNU_STACK header has zero length which effectively means it is unset hence it is assumed to have an executable stack.
I mean, isn't a executable stack required for some forms of JIT compilation? Maybe it's on purpose instead of a accident.
