The PKGBUILD seems to be missing git as a build dependency. The package would not build until I added git to the makedepends array.
By the way, thanks for maintaining a PKGBUILD for this software.
Git Clone URL: | https://aur.archlinux.org/ares-emu.git (read-only, click to copy) |
---|---|
Package Base: | ares-emu |
Description: | Cross-platform, open source, multi-system emulator by Near and Ares team, focusing on accuracy and preservation. |
Upstream URL: | https://ares-emu.net/ |
Licenses: | ISC |
Conflicts: | ares-emu |
Provides: | ares-emu |
Submitter: | Snowstorm64 |
Maintainer: | Snowstorm64 (SoullessSentinel) |
Last Packager: | Snowstorm64 |
Votes: | 22 |
Popularity: | 0.138401 |
First Submitted: | 2021-02-21 21:36 (UTC) |
Last Updated: | 2024-11-04 20:12 (UTC) |
The PKGBUILD seems to be missing git as a build dependency. The package would not build until I added git to the makedepends array.
By the way, thanks for maintaining a PKGBUILD for this software.
I had no idea that parallel-rdp was missing from the archive, there weren't any clue about it from the build output.
Thanks again, I have pushed a new update.
Hoping you see it Snowstorm64: n64 emulation is only 'broken' in v121 because the full content of parallel-rdp is no longer stored in the source archive.
You can run make -C ares/n64/vulkan sync-upstream
in the root directory before building lucia, and that will fetch the code for parallel-rdp.
The same detail applies to the git version also.
Hi SoullessSentinel, I have heard about the awful news, it's a terrible loss for all us...I hope at least that they are in a better place now.
Thanks for the tip, I have now changed the source to point at the Github repository.
I have also activated the development version, it's available at this address: https://aur.archlinux.org/packages/ares-emu-git/
I was hesitant whether to update this package to version 121 because N64 emulation is now broken. I have decided to do so anyways, but I hope that will be fixed soon.
Many thanks and good luck!
The original developer of ares (Near) is sadly no longer with us. I have been appointed the new maintainer by the community around ares, and the license has been changed to ISC.
The new upstream is currently at https://github.com/higan-emu/ares. We are on version 121a (which is the latest release from Near, with some minor amendments to fix some compilation issues).
The gcc-serialize-reserved patch should no longer be required.
'Nightly'/development builds are also available now as well as stable releases, so it may be worth creating an ares-emu.git AUR package also.
I use the legacy driver from Nvidia, I don't think it's that problem.
hiro=qt5 doesn't change the error, neither does hiro=gtk3 compiler=clang++.
It's OK, I can use RetroArch instead or Higan, I just wanted to test Ares. Since its technically a WIP GUI/Core emulator to be implemented into Higan at a later stable stage, I don't think there is much to miss. Some more I'm not sure about the future of Byuus programs.
Thank you my friend, you're very dedicated helping.
Well, with this kind of error it's hard to identify the cause. It may be a video driver issue, a compiler issue, an issue with the graphical toolkit or anything else. Also, Ares is not compatible with Wayland, in that case you may try to launch it with GDK_BACKEND=x11 prepended.
Also, if you're able to modify the PKGBUILD with an AUR helper e.g. paru or yay, you may try to edit the line 37, by changing graphical toolkit to Qt5 (it may want Qt5Core, Qt5Gui and Qt5Widgets as dependecies), e.g.: make hiro=qt5
You may also try to build ares with an alternative compiler, e.g. with Clang instead of GCC: make hiro=gtk3 compiler=clang++
It compiles nicely now, thank you.
Unfortunately the program doesn't start, it gives this error: 'Illegal instruction (core dumped)'.
BSNES and Higan work fine though, maybe its just my old PC.
Thank you very much for your efforts and very fast fix.
And thank you Byuu for your wonderful skills and sharing your impressive coding talent with the world, may you be safe.
Starting with version 11, GCC now reserves _serialize. It should be fixed now, thanks.
Yes, base-devel is installed. The log is here:
:: (1/1) Parsing SRCINFO: ares-emu
==> Making package: ares-emu 120-1 (Di 29 Jun 2021 19:04:52 CEST)
==> Retrieving sources...
-> Downloading ares_v120-source.zip...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 20.1M 100 20.1M 0 0 657k 0 0:00:31 0:00:31 --:--:-- 927k
-> Found LICENSE
-> Found ares-paths.patch
==> Validating source files with sha256sums...
ares_v120-source.zip ... Passed
LICENSE ... Passed
ares-paths.patch ... Passed
==> Making package: ares-emu 120-1 (Di 29 Jun 2021 19:05:26 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found ares_v120-source.zip
-> Found LICENSE
-> Found ares-paths.patch
==> Validating source files with sha256sums...
ares_v120-source.zip ... Passed
LICENSE ... Passed
ares-paths.patch ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Extracting ares_v120-source.zip with bsdtar
==> Starting prepare()...
patching file ares_v120/lucia/lucia.cpp
==> Sources are ready.
==> Making package: ares-emu 120-1 (Di 29 Jun 2021 19:05:33 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting build()...
Compiling libco/libco.c ...
Compiling ruby/ruby.cpp ...
Compiling hiro/hiro.cpp ...
Compiling ares/ares/ares.cpp ...
In file included from ../ares/ares/node/node.hpp:102,
from ../ares/ares/ares.hpp:74,
from ../ares/ares/ares.cpp:1:
../ares/ares/node/system.hpp:10:103: error: macro "_serialize" passed 1 arguments, but takes just 0
10 | auto serialize(bool synchronize = true) -> serializer { if(_serialize) return _serialize(synchronize); return {}; }
| ^
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/x86gprintrin.h:71,
from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/immintrin.h:27,
from ../nall/platform.hpp:63,
from ../ares/ares/ares.hpp:5,
from ../ares/ares/ares.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/serializeintrin.h:37: note: macro "_serialize" defined here
37 | #define _serialize() __builtin_ia32_serialize ()
|
In file included from ../ares/ares/node/node.hpp:102,
from ../ares/ares/ares.hpp:74,
from ../ares/ares/ares.cpp:1:
../ares/ares/node/system.hpp: In member function ‘nall::serializer ares::Core::System::serialize(bool)’:
../ares/ares/node/system.hpp:10:81: error: could not convert ‘((ares::Core::System)this)->ares::Core::System::_serialize’ from ‘nall::function<nall::serializer(bool)>’ to ‘nall::serializer’
10 | auto serialize(bool synchronize = true) -> serializer { if(_serialize) return _serialize(synchronize); return {}; }
| ^~~~~~~~~~
| |
| nall::function<nall::serializer(bool)>
make: ** [../nall/GNUmakefile:176: obj/ares.o] Error 1
==> ERROR: A failure occurred in build().
Aborting...
error making: ares-emu
Pinned Comments
Snowstorm64 commented on 2024-06-09 09:50 (UTC) (edited on 2024-06-09 10:19 (UTC) by Snowstorm64)
The use of
-march=native
is intended by Ares developers for squeezing more performance from your CPU, at the cost of portability. This is critical for some core (e.g. N64), where some extra FPS could make the difference between a playable game and a less playable one. Since this is AUR where one builds a binary for themselves, it makes sense to sacrifice portability for some more performance.If you need to redistribuite the binary, you can edit the PKGBUILD by adding
local=false
to the make line, like this:local=false
sets-march
flag asx86-64-v2
instead ofnative
.