Open OpenSauce04 opened 1 month ago
OK the AUR package is definitely fixed. It now works in a clean chroot. However, it won't build on my system outside of a clean chroot. So this second error is definitely happening.
I have a second program (torzu) that also only builds in a clean chroot on my system. I will investigate to see if the errors i'm getting on my system for the two programs are similar. If they are, it might make it easier to track down.
OK I have an update. There is a package in the extra repository named robin-map. It said that it was installed as a dependency of another package but must've been an orphan. I uninstalled it with no pacman conmplaints and now I no longer get the robin-map error above - both in my pkgbuild outside of chroot (which uses ninja) and also manually.
I'm guessing that with that program installed, cmake is using the installed version of the program instead of the submodule-provided one. Since this is a submodule of a submodule, I wonder if there's a way to fix to always use submodule without going upstream.
I think it's a cmake thing.
@username227 Can you replicate the problem, and then modify the root CMakeLists.txt
file and put
cmake_policy(SET CMP0079 NEW)
set(CMAKE_POLICY_DEFAULT_CMP0079 NEW)
at the top and try again? I think that'll solve the issue, although I'm not 100% sure (and I think maybe only the second one is needed, but I'm not 100% sure either).
OK. Unfortunately didn't make a difference.
Thanks. Looks like that option is needed to get sdl 2.30.6 working with Lime3DS so it'll be in my next dependency PR anyway.
I feel like there's probably a way to fix this with some cmake options, but I'm not a cmake expert so it'll require some playing around. I also feel like I've encountered it before, but if so, it was a long time ago and I may have forgotten what I did to fix it. There's lots of fodder on Google though regarding the error, so maybe finding the right answer will be relatively easy.
Edit: Just curious, but what version of cmake are you running on your Arch machine?
Actually, how are you invoking the build? If you can pass DYNARMIC_USE_BUNDLED_EXTERNALS=1
as a build option (ex. In cmake, pass -DDYNARMIC_USE_BUNDLED_EXTERNALS=1
, it should force it to ignore the installed robin-map package and use the bundled one instead. If it works, that might be the answer for personal or distro-specific builds (The Lime3DS build scripts don't use it, but it's not needed because those packages aren't installed on the build runners in the first place, although there'd be no harm in including it, but then again, how many people actually use the default build scripts to build Lime3DS in the first place? BTW, the option comes from the dynarmic submodule and not Lime3DS).
that sounded so promising......but alas, to my surprise, it still gives the error.
FYI, the build command I was using is: cmake -B build \ -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_C_COMPILER=clang \ -DDYNARMIC_USE_BUNDLED_EXTERNALS=1 \ -DENABLE_QT_TRANSLATION=ON \ -DUSE_DISCORD_PRESENCE=ON \ -DCMAKE_CXX_FLAGS="-O2" \ -DCMAKE_C_FLAGS="-O2"
The ddynarmic was only just now added. but the rest of the command was identical - works without the package installed, doesn't work with it installed.
Grr. Hmm. I feel like if the package check could be bypassed, then it'd default to using the bundled versions. Perhaps DYNARMIC_USE_BUNDLED_EXTERNALS needs to be added to Lime3DS's main CMakeLists.txt
since the package check gets hit there first and maybe that's why the option is ignored.
So maybe modify line 270 in Lime3DS's root CMakeLists.txt
to go from this:
# Use system tsl::robin_map if available (otherwise we fallback to version bundled with dynarmic)
find_package(tsl-robin-map QUIET)
to this:
# Use system tsl::robin_map if available (otherwise we fallback to version bundled with dynarmic)
if (NOT DYNARMIC_USE_BUNDLED_EXTERNALS)
find_package(tsl-robin-map QUIET)
endif()
Would you be willing to make that change locally and see if it works?
I got Lime installed via FlatPak on Arch it works great.
Bump
Grr. Hmm. I feel like if the package check could be bypassed, then it'd default to using the bundled versions. Perhaps DYNARMIC_USE_BUNDLED_EXTERNALS needs to be added to Lime3DS's main CMakeLists.txt since the package check gets hit there first and maybe that's why the option is ignored.
So maybe modify line 270 in Lime3DS's root CMakeLists.txt to go from this:
Use system tsl::robin_map if available (otherwise we fallback to version bundled with dynarmic)
find_package(tsl-robin-map QUIET) to this:
Use system tsl::robin_map if available (otherwise we fallback to version bundled with dynarmic)
if (NOT DYNARMIC_USE_BUNDLED_EXTERNALS) find_package(tsl-robin-map QUIET) endif() Would you be willing to make that change locally and see if it works?
the suggestion, unfortunately, does not seem to fix it on my vanilla Arch install. Edit: it does, however, work on a clean chroot.
still getting the issue on any new arch install without clean chroot
Just to be clear, are you making the CMakeLists.txt
change AND compiling with -DDYNARMIC_USE_BUNDLED_EXTERNALS=1
?
Is there an existing issue for this?
Affected Build(s)
5fc08dd46dd5a50456e4557f4e4d3830c1c00cb9
Description of Issue
This issue follows on from a conversation in #327 User @username227 attempted to compile Lime3DS on their Arch Linux system and encountered the following error:
I have attempted to replicate this issue, and am unable to replicate the issue on my Gentoo system.
Expected Behavior
The project should configure successfully
Reproduction Steps
build
directory viacmake ..
Log File
build.log (1).txt
System Configuration
Copied from the author's original issue:
CPU: AMD GPU/Driver: AMD/Nvidia RAM: 16 OS: Arch