Package Details: duckstation-git 0.1.r6679.g17b9736-1

Git Clone URL: https://aur.archlinux.org/duckstation-git.git (read-only, click to copy)
Package Base: duckstation-git
Description: A Sony PlayStation (PSX) emulator, focusing on playability, speed, and long-term maintainability (git version)
Upstream URL: https://github.com/stenzek/duckstation
Keywords: emulator game gaming psone
Licenses: GPL-3.0-only
Conflicts: duckstation
Provides: duckstation
Submitter: jackdroido
Maintainer: eugene
Last Packager: eugene
Votes: 22
Popularity: 2.01
First Submitted: 2020-04-25 18:24 (UTC)
Last Updated: 2024-04-26 20:40 (UTC)

Required by (0)

Sources (7)

Latest Comments

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

eugene commented on 2023-08-21 12:58 (UTC)

It seems it builds fine with clang

heavysink commented on 2023-08-21 02:11 (UTC) (edited on 2023-08-21 02:12 (UTC) by heavysink)

It seems that it fails to build with the following:

``/usr/src/debug/duckstation-git/duckstation/src/core/achievements.cpp: In function ‘Shutdown.isra’:

/usr/src/debug/duckstation-git/duckstation/src/core/achievements.cpp:124:21: note: declared here

/usr/bin/ld: /tmp/cc1GHPEY.ltrans28.ltrans.o: in function `EmuThread::run()':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:2096:(.text+0x55e3): undefined reference to `fastjmp_set'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans29.ltrans.o: in function `EmuThread::singleStepCPU() [clone .part.0]':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:2139:(.text+0x30b7): undefined reference to `fastjmp_set'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans55.ltrans.o: in function `TimingEvents::RunEvents()':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782:(.text+0x16f4): undefined reference to `fastjmp_jmp'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans39.ltrans.o: in function `void CPU::ExecuteImpl<(PGXPMode)1, true>() [clone .lto_priv.0]':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782:(.text+0x2cde): undefined reference to `fastjmp_jmp'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans37.ltrans.o: in function `CPU::UpdateDebugDispatcherFlag()':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782:(.text+0xb7): undefined reference to `fastjmp_jmp'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans37.ltrans.o: in function `CPU::ClearBreakpoints()':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782:(.text+0x190): undefined reference to `fastjmp_jmp'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans37.ltrans.o: in function `CPU::ExecuteDebug() [clone .lto_priv.0]':

/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782:(.text+0x2c14): undefined reference to `fastjmp_jmp'

/usr/bin/ld: /tmp/cc1GHPEY.ltrans38.ltrans.o:/usr/src/debug/duckstation-git/duckstation/src/core/cpu_core.cpp:1782: more undefined references to `fastjmp_jmp' follow

collect2: error: ld returned 1 exit status``

loathingkernel commented on 2023-08-18 08:58 (UTC)

@exploder-jimmy while I do agree with the premise, the .install file is the wrong way to go about it. There are established procedures on how to handle this case and in this case the current solution and your suggestion don't follow them. There is already a system to do what you are proposing with the .install file and it is the optdepends array. I don't understand why it should be made somehow "clearer" by not following standard procedure.

It is not something it should be in the install file, and it definitely needs to be in the optdepends as it is a makedependency, meaning the package links to whatever qt6-wayland provides.

In short, there is no reason to break standardised procedures with lacking alternatives for something that is essentially a careless user.

exploder-jimmy commented on 2023-08-18 03:48 (UTC) (edited on 2023-08-18 03:58 (UTC) by exploder-jimmy)

@eugene Maybe add an .install file?

Something like this:

duckstation-git.install
---
post_upgrade() {
  echo "If you are running Wayland session, make sure qt6-wayland package is installed."
}

post_install() {
  post_upgrade
}

And remove it from both optdepends and depends, since it's already optional for qt6-base: qt6-wayland: to run Qt6 applications in a Wayland session.

exploder-jimmy commented on 2023-08-18 03:22 (UTC)

I think it is wrong to force a wayland dependency to all users

I think so as well.

@eugene Please see https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette

Any optional dependencies that are not needed to run the package or have it generally function should not be included in the depends array;

loathingkernel commented on 2023-08-17 17:06 (UTC) (edited on 2023-08-17 17:06 (UTC) by loathingkernel)

I think it is wrong to force a wayland dependency to all users when the issue is clearly an oversight by the user in this specific case. The optional dependency is there and pacman will alert for it. I assume there is a reason that most software in Arch is only optionally depending on qt6-wayland unless absolutely necessary.

eugene commented on 2023-08-17 10:15 (UTC)

@ShalokShalom: qt6-wayland was optional dependency, but I think it will be fine to make it mandatory. So be it.

ShalokShalom commented on 2023-08-17 08:35 (UTC) (edited on 2023-08-17 08:36 (UTC) by ShalokShalom)

This is missing a dependency, I think. 

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, xcb.

FabioLolix commented on 2023-08-12 21:01 (UTC)

it's due to format-security which is most likely being forced by makepkg/PKGBUILD settings.

Yes it is forced by makepkg.conf, however format-security isn't a new addition, this is likely a regression upstream because it worked before but issues are disabled on github

noabody commented on 2023-08-12 20:23 (UTC) (edited on 2023-08-12 20:24 (UTC) by noabody)

As FabioLolix pointed out, it's due to format-security which is most likely being forced by makepkg/PKGBUILD settings. You can check with:

grep -A1 -B1 -Pi 'werror' /etc/makepkg.conf 
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"

With that in mind, another option would be to do this in the build section:

+  export CFLAGS="${CFLAGS// -Werror=format-security}"
+  export CXXFLAGS="$CFLAGS"

Which strips format-security out of the global flags being forced by makepkg/PKGBUILD. It should also be possible to do this options=!buildflags but I've never seen it work.

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