Program won't build after latest commits

[username227]

Is there an existing issue for this?

• I have searched the existing issues

Affected Build(s)

Latest master 10317

Description of Issue

Program no longer builds.

Expected Behavior

Expect the program to build properly.

Reproduction Steps

I'm using Arch Linux, see log below.

Log File

[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/applets/swkbd.cpp.o
In file included from /home/jerry/Lime3DS/src/core/gdbstub/hio.cpp:5:
/home/jerry/Lime3DS/externals/fmt/include/fmt/ranges.h:211:49: error: self-comparison always evaluates to true [-Werror=tautological-compare]
211 | integer_sequence<bool, (Is == Is)...>) -> std::true_type;
| ~~~^~~~~
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/address_arbiter.cpp.o
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/client_port.cpp.o
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/client_session.cpp.o
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/config_mem.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/event.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/handle_table.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/hle_ipc.cpp.o
cc1plus: note: unrecognized command-line option ‘-Wno-unused-command-line-argument’ may have been intended to silence earlier diagnostics
cc1plus: all warnings being treated as errors
make[2]: *** [src/core/CMakeFiles/lime_core.dir/build.make:941: src/core/CMakeFiles/lime_core.dir/gdbstub/hio.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:2553: src/core/CMakeFiles/lime_core.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

System Configuration

CPU: AMD
GPU/Driver: AMD/Nvidia
RAM: 16
OS: Arch

[username227]

Several other points that hopefully will be helpful. May be related or not. Depending on how I build it, i'm getting one of several errors:

1. This happens when I build from the pkgbuild arch file that I made. i've been troubleshooting it but it happens invariably. Make Error at /home/jerry/Desktop/Untitled Folder_2/src/Lime3DS/CMakeModules/GenerateSCMRev.cmake:2 (include):
   include could not find requested file:

   GenerateBuildInfo

make[2]: *** [src/common/CMakeFiles/lime_common.dir/build.make:106: src/common/scm_rev.cpp] Error 1
make[1]: *** [CMakeFiles/Makefile2:2526: src/common/CMakeFiles/lime_common.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

2. Alternatively, if I build manually with clang, it goes until around 95% and then says: clang++: error: linker command failed with exit code 1 (use -v to see invocation)
   and exits.

[username227]

And if I build it without clang manually, it gets to about 86% and then gives me the following error:

In file included from /home/jerry/Lime3DS/src/core/gdbstub/hio.cpp:5:
/home/jerry/Lime3DS/externals/fmt/include/fmt/ranges.h:211:49: error: self-comparison always evaluates to true [-Werror=tautological-compare]
211 | integer_sequence<bool, (Is == Is)...>) -> std::true_type;
| ~~~^~~~~
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/client_port.cpp.o
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/client_session.cpp.o
[ 86%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/config_mem.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/event.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/handle_table.cpp.o
[ 87%] Building CXX object src/core/CMakeFiles/lime_core.dir/hle/kernel/hle_ipc.cpp.o
cc1plus: note: unrecognized command-line option ‘-Wno-unused-command-line-argument’ may have been intended to silence earlier diagnostics
cc1plus: all warnings being treated as errors
make[2]: *** [src/core/CMakeFiles/lime_core.dir/build.make:941: src/core/CMakeFiles/lime_core.dir/gdbstub/hio.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:2553: src/core/CMakeFiles/lime_core.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

[username227]

OK - i've been troubleshoot this, and i've concluded that the error in # 1 above (two posts ago) is not related to the program but must be something about the way make is configured on my machine so please ignore.

The main issue preventing building with clang is the error in # 2 there -

clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/lime_qt/CMakeFiles/lime-qt.dir/build.make:2028: bin/None/lime-qt] Error 1
make[1]: *** [CMakeFiles/Makefile2:2921: src/lime_qt/CMakeFiles/lime-qt.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
==> ERROR: A failure occurred in build().

[OpenSauce04]

I can compile just fine, as can GitHub Actions. It must be something on your end
Have you tried a clean clone of the repo?

[username227]

Yes. After I fixed my pkgbuild, I successfully ran it in a clean chroot so that nothing on my side could interfere. I had the same result. I can try recloning the normal way again and starting from scratch but I expect the same.

I'll try to go back and clone old versions of the repo before the latest commit which built fine on Friday and try to identify a commit where the problem starts. I'll report back

[username227]

No, the commit that built perfectly on Friday no longer builds. not sure what the difference is. I'm attaching the full log where you can see all of the steps i took. the error happens at the end around 85% built.

This is with the standard compiler, not clang. Using clang, I get a different error when linking.
make text.txt

[username227]

clang log.txt

This log is the same detailed log as above but building with clang.

[s0mebodyhelpme]

Getting the exact same error on a fresh install of Arch when compiling either with clang manually or the AUR PKGBUILD.

[edbefee3-3888-462a-9411-741b7e9eb54e]

On GCC, I get the same tautological compare error, on Clang I get a linker error for SpvTools.cpp at every instance of optimizer.Run(spirv.data(), spirv.size(), &spirv, spvOptOptions);

[rtiangha]

Can you install SPIRV-Tools and try again?

[username227]

I actually looked into this yesterday. It is already installed. However, just to be thorough, I added it to makedepends on my pkgbuild and tried it in a clean chroot - same result.

[rtiangha]

How about manually updating externals/glslang? The one Lime3DS is configured to pull in is 14.1.0 but the latest is 14.2.0 (and change, if you count HEAD) and perhaps there's some newer commits there that will fix the build errors (I don't see anything in their commit history that's obvious, but who knows).

Edit: And I suppose another thing to try is to uninstall SPIRV-Tools and try again; maybe the build is getting confused as to what to link to, although I don't know why Arch is acting so different.

[username227]

OK that didn't make a difference when pulling and placing the latest master of glslang in the externals folder.

Removing the spirv-tools package is complicated, it's at least three levels of dependencies deep so i'm worried i'd screw up something important. However, when building my pkg in a clean chroot, in theory, spirv-tools should not be installed when it's not added to makedepends, so i'm thinking that we already may know the answer is that it won't help.

[rtiangha]

How about using ninja to build? What GitHub actions does is this:

mkdir build && cd build
cmake .. -G Ninja \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_C_COMPILER_LAUNCHER=ccache \
    -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
    -DCMAKE_CXX_COMPILER=clang++-18 \
    -DCMAKE_C_COMPILER=clang-18 \
    "${EXTRA_CMAKE_FLAGS[@]}" \
    -DENABLE_QT_TRANSLATION=ON \
    -DCITRA_ENABLE_COMPATIBILITY_REPORTING=ON \
    -DENABLE_COMPATIBILITY_LIST_DOWNLOAD=ON \
    -DUSE_DISCORD_PRESENCE=ON
ninja
strip -s bin/Release/*

You can probably take out

    -DCMAKE_C_COMPILER_LAUNCHER=ccache \
    -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
    -DCMAKE_CXX_COMPILER=clang++-18 \
    -DCMAKE_C_COMPILER=clang-18 \
    "${EXTRA_CMAKE_FLAGS[@]}" \
    -DCITRA_ENABLE_COMPATIBILITY_REPORTING=ON \
    -DENABLE_COMPATIBILITY_LIST_DOWNLOAD=ON \

and be fine, but perhaps ninja links things in a way that regular cmake doesn't.

Edit: The full Linux build script is here.

[username227]

it's erroring out because it's looking for: CMAKE_BUILD_WITH_INSTALL_RPATH that needs to be manually set

[s0mebodyhelpme]

It actually compiled for me with ninja. This is what I used:

cmake .. -G Ninja \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER=clang \
    -DENABLE_QT_TRANSLATION=ON \
    -DUSE_DISCORD_PRESENCE=ON
ninja
strip -s bin/Release/*

[username227]

OK, seems to. i'll work out the pkgbuild and put out an aur update shortly. I consider this a workaround, but there's no reason why we can't use ninja instead. I wonder what the heck the problem was.

[rtiangha]

Yeah, my guess is how cmake generates the make files. I've always had issues compiling Citra making cmake generate regular Makefiles; there was always an issue with linking. Making it configure Ninja formatted Makefiles seemed to fix things, although I haven't gotten modern Citra to compile with gcc that way either (it worked back in the QT5 days).

I'm glad it worked out but if you're still open to some experimentation, I quickly made a branch that explicitly links glslang to the three executables. I'm not sure if PRIVATE INTERFACE glslang::glslang is actually needed (I asssume PRIVATE INTERFACE glslang::SPIRV is though) and it's still building for the various OSes so I don't know if it'll compile successfully (and I'd probably want to clean it up a bit first before submitting a PR), but if you wanted to test it, clone this tree/branch:

https://github.com/rtiangha/Lime3DS/tree/link-glslang

But honestly, all the Citra forks are using ninja for release builds meaning that's the system that gets the most testing, so if no one is objecting, maybe Arch should switch to it as well and make it one less thing to worry about.

[username227]

i'll test but i can't seem to clone. is there a password needed or something?

[rtiangha]

I think you'd have to clone it this way:

git clone -b link-glslang https://github.com/rtiangha/Lime3DS.git

[username227]

still get the same errors. sorry.

[rtiangha]

Well, now we know! Thanks.

[username227]

OK the arch package has been updated to ninja. i will be happy to continue to test this for you. Let me know.

[rtiangha]

Actually, could you do a git pull and try one more time? This time, I'm linking all of glslang rather than just a piece of it. This is just for my curiosity since I don't have access to an Arch instance to test on.

[username227]

Same result. The past two attempts have only been with clang - i assume that these troubleshooting steps are directed at the error using clang, not the error using the regular method.

[rtiangha]

Yes; correct. I stopped trying to build with gcc a while ago because it'd always throw linking errors with cryptopp and I could never figure out how to fix it. Every other compiler seemed to work fine.

Ah well, thanks for the help with testing. At least I won't be losing sleep over how to solve this, lol.

[username227]

yes, the error at around 86% (or possibly 76%) was right after cryptopp - but I had been thinking that cryptopp was compiling okay and whatever comes immediately after cryptopp was causing the problem. But I agree, I don't think it is such a big deal now that we have another option.

[rtiangha]

As an aside, I was looking at your PKGBUILD. If you wanted to, you could probably pass -DCMAKE_CXX_FLAGS="-O2" and -DCMAKE_C_FLAGS="-O2" as flags too. But I'm glad everything works now.

[username227]

OK I'll add these two. The suggestion that you deleted when you edited won't seem to work because it gave me conflicts with enet files that it said were identical already in the file system. So I suppose we should leave it at usr/local to avoid conflicts.

[OpenSauce04]

I can build with both GCC and Clang, so it must be a system-specific issue in some way.
In any case it seems like you found a workaround, so I will now close this issue as user error. If it is determined that there is a tangible issue with the build process which can be replicated across distros and build environments, a separate issue can be opened

[username227]

can you do me a favor when you get a chance? I'm trying to get a pkgbuild going that will build the latest release version. this is somewhat more complicated since you don't have a separate branch in github.

I have a pkgbuild here: https://aur.archlinux.org/packages/lime3ds - when I build this, however, it does not show the release number even though it clones the release tag #. Rather, it seems to have some sort of hash, so there's no way to verify that it's building correctly. I'd rather it say Lime3DS 2113 like the appimage says. Is there a way to tweak the git command to correct this?

Truth is, what I'd REALLY like to do is to download the source code tar.gz in the pkgbuild, transform it into a git repository with git init or something like that, and then build from there; i'm thinking this might solve the problem. however, I can't get the submodules to work properly when I do this. I've asked the arch people to help out with this: https://www.reddit.com/r/archlinux/comments/1cw5jq3/pkgbuild_help_please/

If you're busy it's not urgent, but if you have any quick insights, i'd be grateful. thanks.