Tatsh / tatsh-overlay

Personal Gentoo Portage overlay.
https://tatsh.github.io/tatsh-overlay/
GNU General Public License v2.0
35 stars 10 forks source link

games-emulation/rpcs3 - Needs patch for LLVM 17 Systems #259

Closed ThisNekoGuy closed 5 months ago

ThisNekoGuy commented 5 months ago

The Guru package has a bug related to this (https://bugs.gentoo.org/922263), but I wanted to report here that the patch that solves this issue over there for the live ebuild doesn't work for this overlay's package to get the emulator to build.

Log (without patch): rpcs3-tatsh-build.log

Tatsh commented 5 months ago

Can you try the change I just pushed? The issue is that cmake.eclass has moved to disable precompiled headers by default. The change I just pushed re-enables them. This would also fix the 9999 issue without patches. Later on I will make patches to add missing header includes and disable PCH.

ThisNekoGuy commented 5 months ago

I emerge --synced and ran the build again but I still seem to be getting the same build failure. :/

rpcs3-tatsh-build.log

Tatsh commented 5 months ago

Please confirm you have the latest ebuild. You should get same output as below:

# grep -F CMAKE_DISABLE_PRECOMPILE_HEADERS=OFF /var/db/repos/tatsh-overlay/games-emulation/rpcs3/rpcs3-0.0.30-r2.ebuild
                -DCMAKE_DISABLE_PRECOMPILE_HEADERS=OFF

(Fix ebuild path as necessary.)

Tatsh commented 5 months ago

I switched to Clang and matched your USE flags in my testing and I still cannot reproduce this issue. It looks like adding includes will solve it but I am not so sure.

Please try the -r3 version where I have included an adapted patch from https://github.com/RPCS3/rpcs3/pull/15075. This looks like it may solve the issue assuming no other includes are required.

ThisNekoGuy commented 5 months ago

Please confirm you have the latest ebuild. You should get same output as below

I ran that but it didn't return any output.

Please try the -r3 version

I re-synced, and the ebuild updated to r3 but the build still fails; which is odd, because that patch you mentioned that links to the original Guru bug page I filed does work with guru's 9999 ebuild to finish emerging, so I don't understand why it wouldn't work here.

Tatsh commented 5 months ago

Please post the latest build log.

ThisNekoGuy commented 5 months ago

Sorry about that, I meant to but hit comment early because my train of thought trailed off for a moment: rpcs3-tatsh-build.log

Tatsh commented 5 months ago

I think I figured out the issue. My version is too old for that exact patch in the PR. JIT.cpp was renamed since then so it never gets patched to include the needed header. I have rebased and remade the patches including the one in the PR. I think this should fix it. My patches were a little wonky.

I think this is related to a transient header issue since I don't get the issue on my machines. Somehow my toolchain is implicitly including unistd.h but yours is not. Has nothing to do with precompiled headers.

ThisNekoGuy commented 5 months ago

This seems to work now, yeah. :+1: Setting a new Emulator Filesystem Dir folder to a different drive from the default (for storage space reasons), though, causes RPCS3 to crash upon applying the configuration and crash immediately upon subsequent launches. :/ I can't use it like this (though it is admittedly off-topic).

RPCS3.log

Debugger: 0
/usr/include/c++/v1/string:1320: assertion !empty() failed: string::back(): string is empty
fish: Job 1, 'rpcs3' terminated by signal SIGABRT (Abort)

As far as I can tell from the log, it just isn't adding the new folder path and seems to be crashing because it wasn't expecting it to be empty. Correct me if I'm wrong though.

Tatsh commented 5 months ago

I get the same crash. Definitely a bug on the part of RPCS3. However, they probably disable assertions in their builds so nobody sees this.

You will have to edit ~/.config/rpcs3/vfs.yml manually. You can also delete the file so default is used.

Closing this. Thanks for reporting and testing this.

ThisNekoGuy commented 5 months ago

@Tatsh One last thing, about that, the correct path is already in vfs.yml so I'm not entirely sure where this is being triggered. I would submit a bug report for this upstream, but I have no idea when this regression started and their regression report form desires it. (I've tried bisecting once before for something else a long time ago but I never really properly figured it out, I recall)