| Git Clone URL: | https://aur.archlinux.org/pcsx2-git.git (read-only, click to copy) |
|---|---|
| Package Base: | pcsx2-git |
| Description: | PlayStation 2 emulator |
| Upstream URL: | https://github.com/PCSX2/pcsx2 |
| Licenses: | GPL-3.0-or-later |
| Conflicts: | pcsx2 |
| Provides: | pcsx2 |
| Submitter: | alucryd |
| Maintainer: | weirdbeard (xiota) |
| Last Packager: | weirdbeard |
| Votes: | 131 |
| Popularity: | 0.35 |
| First Submitted: | 2014-03-26 14:17 (UTC) |
| Last Updated: | 2025-03-25 20:47 (UTC) |
My only concern is it breaks in the future because of some change or, another. And we'll have to re-up the other pcsx2 package on this which is why I did the package style I did in the first place, lower maintenance cost on both fronts.
That said if you guys are absolutely adamantly certain this is the better way, that's fine.
@xiota Yeah, that was sort of my point. setcap is run in post_install, so if we use patchelf in build or install, setcap capabilities would not be removed. I like this approach though, set rpath, build lib with pcsx2, move it to opt with the binary, etc.
@weirdbeard, do you have any thoughts?
@patlefort Which capabilities are you referring to? The appiamge build script in the pcsx2 repo uses linuxdeploy to create the AppDir, which when passed the --library flag uses patchelf to set the rpath on the binary to $ORIGIN/../lib. You can check this against the binary packed in the appimage.
About patchelf: If you use --add-rpath, it will undo setcap which could explain why it suddenly start working. EDIT: if patchelf modifies anything in the executable, capabilities are lost.
My pcsx2 executable is setcapped /opt/pcsx2/pcsx2-qt cap_net_admin,cap_net_raw=eip and rpath is working. I'm really curious as to what is different that would cause rpath to not work on his system.
@xiota That could definitely work. Adversely, I just tested adding 'libshaderc_shared.so.1' to pcsx2-qt's DT_NEEDED section using patchelf and with the rpath set during build I get this output from ldd:
ldd /opt/pcsx2/pcsx2-qt
linux-vdso.so.1 (0x000073386eb26000)
libshaderc_shared.so.1 => /opt/pcsx2/libshaderc_shared.so.1 (0x0000733860400000)
...
It needs more testing but it seems to be working (I was able to load into burnout 3 and compile new shaders). I don't know if ̶t̶h̶a̶t̶ ̶w̶o̶u̶l̶d̶ ̶l̶o̶a̶d̶ ̶a̶ ̶s̶e̶c̶o̶n̶d̶ ̶i̶n̶s̶t̶a̶n̶c̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶l̶i̶b̶ ̶i̶n̶t̶o̶ ̶m̶e̶m̶o̶r̶y̶ ̶o̶r̶ ̶i̶f̶ that would cause problems though (Note: The posix spec states Only a single copy of an object file is brought into the address space, even if dlopen() is invoked multiple times in reference to the file so it should be okay to do this). Really I don't see any way around this that isn't either hacky or patchy, so both methods could work. Your method probably has the cleanest result and I'm kind of leaning that way.
Perhaps the name could even be 'libshaderc_pcsx2' and the lib could be installed to /usr/lib, removing the need to mess with rpath and ld cache even. That way duckstation could depend on a differing patchset and not find the wrong lib.
@xiota I think that approach would cause any binary looking for libshaderc_shared.so.1 without a runpath or rpath, or without LD_LIBRARY_PATH set beforehand to load /opt/pcsx2/libshaderc_shared.so.1. Unfortunately, I can't be much direct help because I'm having no issues with rpath and setcap or loading the wrong library, and I have the upstream shaderc installed as well even. It's too bad that changing the name of this library isn't part of the patchset...
Pinned Comments
weirdbeard commented on 2024-08-17 03:40 (UTC)
https://github.com/PCSX2/pcsx2/pull/11632
This package now enables Cmake Package mode proper. PCSX2 will here on, be installed in the package standard folders /usr/bin, /usr/share, /usr/lib. Following the XDG standard pcsx2's config files remain in .config/PCSX2
In order to ensure a proper and clean upgrade. Uninstall this package COMPLETELY and clear cache before reinstalling.