Package Details: pcsx2-git 2.3.119.r1.g9e21ee1bc4-1

Git Clone URL: https://aur.archlinux.org/pcsx2-git.git (read-only, click to copy)
Package Base: pcsx2-git
Description: A Sony PlayStation 2 emulator
Upstream URL: https://github.com/PCSX2/pcsx2
Licenses: GPL-3.0+
Conflicts: pcsx2
Provides: pcsx2
Submitter: alucryd
Maintainer: weirdbeard (xiota)
Last Packager: weirdbeard
Votes: 130
Popularity: 0.070665
First Submitted: 2014-03-26 14:17 (UTC)
Last Updated: 2025-01-19 15:42 (UTC)

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 67 Next › Last »

xmusjackson commented on 2024-06-07 13:08 (UTC) (edited on 2024-06-07 13:13 (UTC) by xmusjackson)

@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.

patlefort commented on 2024-06-07 11:41 (UTC) (edited on 2024-06-07 13:19 (UTC) by patlefort)

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.

patlefort commented on 2024-06-07 11:27 (UTC)

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.

xmusjackson commented on 2024-06-07 06:39 (UTC) (edited on 2024-06-07 07:44 (UTC) by xmusjackson)

@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.

xmusjackson commented on 2024-06-07 06:22 (UTC) (edited on 2024-06-07 06:26 (UTC) by xmusjackson)

@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...

xmusjackson commented on 2024-06-07 05:55 (UTC)

@xiota Thanks. I didn't spend enough time to dig into the classes.

xmusjackson commented on 2024-06-07 05:39 (UTC) (edited on 2024-06-07 05:58 (UTC) by xmusjackson)

@patlefort Can you find in the code where dlopen is used to load libshaderc_shared.so.1 or are you speculating? That was my thought as well but I'm unable to find such a line. However, in the file cmake/FindShaderc.cmake of the pcsx2 source are the lines:

if(SHADERC_FOUND)
    add_library(Shaderc::shaderc_shared UNKNOWN IMPORTED)

Meaning that shaderc is (supposed to be) linked in like normal.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 67 Next › Last »