Arch Linux User Repository

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.

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

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

To further clarify, one of the major issues I had, had was linking to glslang and spriv when building locally. Something the package version has no issue with and ended up in the ppa having to be manually patched

Because when you try to in a friendly manner apply the patched shaderc directly to pcsx2 things get sideways in a lot of ways very quickly. You'll end up eventually modifying patches. It's something about manually building it together with PCSX2 in the AUR environment that caused a bunch of linker and other issues.

My earlier comment was meant to display the maintainer for the ubuntu PPA had similar issues and it went ... Interesting.

The other issue is, if there's anymore patched updates that cause similar issues. I feel it could be better mitigated by keeping it separate from the pcsx2 package. And, having a separate AUR package better serves, the main pcsx2 package and potentially any DuckStation packages should they end up having issues.

@xiota I must be missing something; What do upstream issues have to do with whether you package this modified library separately or build and include it with this package? Once the upstream issues are resolved, this PKGBUILD will have to be updated to reflect the use of upstream shaderc anyway. I'm not impatient, I've already done what I consider to be the correct course of action for this package, I just feel that the current approach doesn't make much sense.

Package was already updated to resolve that issue.

I don't see where, line 144 of the PKGBUILD: install -Dm644 -t "${pkgdir}"/opt/"${pkgname%-git}" "/usr/lib/shaderc-non-semantic-debug/libshaderc_shared.so.1" I realize shaderc-non-semantic-debug was moved to makedepends so that it could be uninstalled from the system when building is done (as long as the user doesn't opt to keep makedeps, as some might), but don't you see how this is the wrong approach? There should not be a package installed on the system so that a file can be copied from it before it's uninstalled.

Your modified PKGBUILD does the same.

It does, I realized later that in this instance it shouldn't cause a problem. I'm not sure why but originally pcsx2 was looking in /usr/lib for shaderc_shared.so.1 instead of /opt/pcsx2 but the problem resolved itself, though it doesn't hurt to be explicit in this case. This comment could be ignored if you wish, the other point is still relevant though. Edit: This was from a previous commit that was overwritten before I squashed them, if you're curous:

-DCMAKE_INSTALL_RPATH="/opt/pcsx2" -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON

Upstream patching of shaderc is causing problems for a few packages and their maintainers.

Please explain the relevance of this. I'm not trying to be dense, I simply don't understand why this means we have to create another package to install on the system. I'm not asking that we switch to upstream, and I'm not just complaining because there is a second package, I just don't see the logic in this separate package when it will only ever be used by pcsx2 and only temporarily at that (once the previously mentioned issued are ironed out it will be removed from this PKGBUILD I assume) and feel I should speak up.

I'm also can't run on Vulkan.

This error is on the log: Failed to find function shaderc_compilation_status_to_string