Package Details: pcsx2-git 2.3.35.r0.g4eae1b7127-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.132736
First Submitted: 2014-03-26 14:17 (UTC)
Last Updated: 2024-11-27 22:52 (UTC)

Dependencies (34)

Required by (4)

Sources (2)

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 .. 12 13 14 15 16 17 18 19 20 21 22 .. 67 Next › Last »

weirdbeard commented on 2023-01-12 02:20 (UTC)

Welp, fixed my mistake I guess... That's weird as hell though that, that's what caused AR to break

niobium93 commented on 2023-01-11 16:14 (UTC)

Can confirm you definitely need llvm in the makedepends. That and removing /usr/bin/ from the compiler variables fixes the issue on my end.

niobium93 commented on 2023-01-11 16:02 (UTC)

Wait, I fixed it. Just do 

    -DCMAKE_C_COMPILER=clang \
    -DCMAKE_CXX_COMPILER=clang++ \

No /usr/bin/. That fixes the CMAKE_C_COMPILER_AR-NOTFOUND issue. You may or may not also need llvm in the makedepends.

niobium93 commented on 2023-01-11 15:32 (UTC)

It's failing with CMAKE_C_COMPILER_AR-NOTFOUND on the Chaotic build server too.

I don't think turning off LTO or using GCC are viable solutions. I vote for the -DCMAKE_AR=/usr/bin/llvm-ar option. (And maybe llvm-ranlib too?)

weirdbeard commented on 2023-01-09 20:43 (UTC)

Can I get a count of how many are experiencing this AR issue? Reason I'm asking is because this is a very ... Inconsistent issue meaning it doesn't happen on every machine and it doesn't happen every time. I can make it happen to me if I drop lld but it'd work on another machine vice versa. The only solid fix to this is either turning off LTO, or using GCC. Stenznek is very insistent that every thing be clang LTO which is why we're experiencing this.

It works for me, and KamFrento on the discord. I can switch to LLVM AR but I'm not certain that's the real fix as much as a work around for some given how sporadic and random it happens. I can't emphasize that enough as much of an unfortunate situation as that is.

eugene commented on 2023-01-09 18:27 (UTC) (edited on 2023-01-09 18:27 (UTC) by eugene)

For me build was failing with CMAKE_C_COMPILER_AR-NOTFOUND, CMAKE_CXX_COMPILER_AR-NOTFOUND and CMAKE_C_COMPILER_RANLIB-NOTFOUND errors. I was able to make it work by addition of llvm to makedepends and setting -DCMAKE_AR=/usr/bin/llvm-ar and -DCMAKE_RANLIB=/usr/bin/llvm-ranlib cmake options.

weirdbeard commented on 2023-01-09 14:10 (UTC)

Alright, since despite it doing so on my machine it's then clear that it's not on others. I've moved the exports to cmake options. Should resolve that issue

rodrigo21 commented on 2023-01-09 06:20 (UTC)

It's not using clang on my machine. Tried in a chroot and still is using gcc.

weirdbeard commented on 2023-01-08 15:53 (UTC)

It definitely is. Earlier it was crashing on some old clang specific code in gtest

niobium93 commented on 2023-01-08 06:45 (UTC)

I still don't think it's using clang.

-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0

Maybe we need to pass options to cmake like this?

    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER=clang \
    -DCMAKE_C_FLAGS="$CFLAGS -flto=thin" \
    -DCMAKE_CXX_FLAGS="$CXXFLAGS -flto=thin" \

Or maybe export those envvars in the build function?

« First ‹ Previous 1 .. 12 13 14 15 16 17 18 19 20 21 22 .. 67 Next › Last »