Package Details: pcsx2-git 2.3.240.r2.g23c495b939-1

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)

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 .. 7 8 9 10 11 12 13 14 15 16 17 .. 70 Next › Last »

xmusjackson commented on 2024-06-06 03:59 (UTC) (edited on 2024-06-06 21:13 (UTC) by xmusjackson)

@rodrigo21 Does the appimage allow you to use vulkan? You could try doing as linuxdeploy does during the appimage build and patch the rpath in the pcsx2-qt binary: sudo patchelf --set-rpath '/opt/pcsx2' /opt/pcsx2/pcsx2-qt Though if you did build from my repo after I pushed the latest commit, then you likely have already tried this (assuming you ran 'git pull' on my repo after I pushed that commit).

@xiota I believe rpath should be explicit for this package. Check linux-build-qt.sh, appimage-qt.sh, then dig through the source code of linuxdeploy and you will see what I mean. If we're to use a custom version of a library with the same name as an existing system library, and then place it alongside the binary on /opt without setting the rpath, how can we expect it to reliably check /opt/pcsx2 for the library when the linux mechanism to do that is rpath? Please read here: https://man7.org/linux/man-pages/man8/ld.so.8.html, you will see that the binary path is never a place the system will look for a library of it's own accord. This package built as is builds the binary with no rpath set at all. That said, I'd have to agree with you that there are further issues with this package (perhaps just the way pcsx2 is written currently).

rodrigo21 commented on 2024-06-06 03:15 (UTC)

@xiota Nope. Same error.

rodrigo21 commented on 2024-06-06 02:18 (UTC) (edited on 2024-06-06 02:19 (UTC) by rodrigo21)

@xiota Same error.

At least OpenGL is working fine.

rodrigo21 commented on 2024-06-05 13:31 (UTC)

@xiota It's the Log Window in Tools > Enable Log Window.

@xmusjackson I already tried your package built in a clean chroot and had the same error.

weirdbeard commented on 2024-06-05 05:01 (UTC)

@xiota, oh trust me. I have a PKGBUILD that works and does that, that a buddy of mine drafted up.

As for the issues you listed

  1. I'll likely change the patched shaderc to match what's on the pcsx2 repo and yeah for them I could semi see that being an issue? But 99.9% of the time he's kept the two in sync with each other, IE. What's pushed to Duck is pushed to pcsx2 vice versa if it's applicable given one's a PS1 emu and the other's a PS2 emu

  2. Its pulling the patch from the repo directly so patch wise not likely, and I have plenty of eyes and sources to warn me when there's a patch update that might bork like a version change in shaderc or what have you.

@xmusjackson: Yes, yes I am. And Xiota's the one that helped me figure out the path move with shaderc hence him being able to answer somewhat. That said as for it working for you and not me, I've had countless times when maintaining these packages where things worked for person A, not person B, like with rodrigo's issue. I have another guy on Discord (Assuming rodrigo isn't the same guy) that has that same issue and it still doesn't work for him either way

Discord guy is able to run it with the flatpak since its basically a glorified VM with ubuntu dependencies but not with the package no matter what way it is or isn't built.

I feel having the package separated like this prevents a good amount of those kinds of issues from occurring with a direct patch.

Also, if we want to keep having back-and-forths like this is fine here since I get the emails, but I'm also available on Discord (weirdbeardgame)

xmusjackson commented on 2024-06-05 04:35 (UTC) (edited on 2024-06-05 05:01 (UTC) by xmusjackson)

@weirdbeard Are you building in a clean chroot? I've had no such linker issues when building altogether and I'm just following the process used when building the appimage. You can build from my repo to see for yourself. However, having a separate package for this library could be okay even, especially if you think there could be other packages that want to use this specific patchset, but you probably shouldn't copy the library from one package to another, you should rather build pcsx2 and link it with the library in place (/usr/lib/shaderc-non-semantic-debug). You could replace -DCMAKE_SKIP_RPATH with -DCMAKE_INSTALL_RPATH="/usr/lib/shaderc-non-semantic-debug" -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON unless there's something further I'm missing.

@rodrigo21 I ran into the same issue a few days ago when I first forked this package. PCSX2 is looking for a function added and exported by the patchset within what's likely the upstream shaderc (it's probably using the one present in /usr/lib. It's also possible you have an outdated version of shaderc-non-semantic-debug installed, which would require rebuilding and installing that package and then rebuilding pcsx2, or you could try building from my repo after the latest commit which reverts to using an explicit rpath.

@xiota Why did you respond to my comment as though you were the maintainer? I was replying to them when you posted your reply; I thought you were a comaintainer or something.

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 .. 70 Next › Last »