Arch Linux User Repository

getting compiling errors on limne3ds and mandarine - looks like it has something to do with boost.

[821/951] Building CXX object src/core/CMakeFiles/lime_core.dir/rpc/udp_server.cpp.o FAILED: src/core/CMakeFiles/lime_core.dir/rpc/udp_server.cpp.o /usr/bin/clang++ -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_DATE_TIME_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_NO_CXX98_FUNCTION_BASE -DBOOST_REGEX_NO_LIB -DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SERIALIZATION_NO_LIB -DBOOST_SYSTEM_NO_LIB -DENABLE_OPENGL -DENABLE_SCRIPTING -DENABLE_SOFTWARE_RENDERER -DENABLE_VULKAN -DENABLE_WEB_SERVICE -DFMT_SHARED -DHAVE_CUBEB -DHAVE_OPENAL -DNDEBUG -D_FILE_OFFSET_BITS=64 -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/src/. -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/./dds-ktx -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/xbyak -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/cryptopp -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/lodepng/lodepng -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/open_source_archives/include -I/var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/dynarmic/src/dynarmic/.. -isystem /var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/./library-headers/ffmpeg/include -isystem /var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/./microprofile -isystem /var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/externals/./httplib -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/var/tmp/pamac-build-jerry/lime3ds-git/src=/usr/src/debug/lime3ds-git -flto=thin -std=gnu++20 -flto=thin -fvisibility=default -Wall -Wno-unused-command-line-argument -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2 -Werror -DCPPHTTPLIB_OPENSSL_SUPPORT -Winvalid-pch -Xclang -include-pch -Xclang /var/tmp/pamac-build-jerry/lime3ds-git/src/build/src/core/CMakeFiles/lime_core.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /var/tmp/pamac-build-jerry/lime3ds-git/src/build/src/core/CMakeFiles/lime_core.dir/cmake_pch.hxx -MD -MT src/core/CMakeFiles/lime_core.dir/rpc/udp_server.cpp.o -MF src/core/CMakeFiles/lime_core.dir/rpc/udp_server.cpp.o.d -o src/core/CMakeFiles/lime_core.dir/rpc/udp_server.cpp.o -c /var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/src/core/rpc/udp_server.cpp In file included from /var/tmp/pamac-build-jerry/lime3ds-git/src/Lime3DS/src/core/rpc/udp_server.cpp:6: In file included from /usr/include/boost/asio.hpp:69: /usr/include/boost/asio/co_composed.hpp:849:13: error: unknown type name 'async_operation'

@username227, I forgot to add boost to the make depends. You need boost to makedepends and boost-libs for running the program. I will ensure everything builds correctly.

Using system libraries cuts down on compilation by a 1000 jobs. Of course, if you use system libraries, it is the responsibility of the maintainer to keep a watchful eye to ensure compatibility with upstream updates. For example, you can look at the godot package and see how it enables upstream libraries.

OK, first of all, I really appreciate the suggestions. Everything I learned about pkgbuilds was self-taught.

what is the advantage of using the system boost, and all the other dependencies instead of the ones from the submodules? Your patch fails because it's looking for the system boost but boost wasn't in the dependencies. I will make the changes with boost in depends in order to make it work. However, I would be very interested in knowing why you feel it's better to use the system versions for this - we might be asking for trouble if something changes from arch.

Hello, as the past maintainer for citra related projects on AUR, I have some suggestions for this package that you may have already ready at lime3ds and citra-git.

1. Change license from GPL-2.0 to GPL-2.0-only to be SPDX compliant
2. Remove the DCMAKE_C_FLAGS and DCMAKE_CXX_FLAGS. Citra cannot build due to the Warrning Protection from Foritfy Source. However, that does not mean the rest of the Arch build flags should be disregarded. Instead, in the patch, I have removed -Wp,-D_FORTIFY_SOURCE=3 using sed, and the project builds fine with the default Arch flags defined in /etc/makepkg.conf. Therefore, there is no longer any reason to disable buildflags in options().
3. Don't use the Release cmake build type, as explained here. Instead, use the None build type; this goes hand in hand with point 2.
4. Remove libc++. Citra has no specific need for libc++, nor does it call upon it during a clean chroot build.
5. Use system libraries. This cuts the amount of files needed to compile in almost half.
6. Use ThinLTO instead of normal LTO with clang to speed up build times.
7. Add conflicts and provides as this is a git package.
8. Missing dependencies.

Here is the link to the patch file.

OK, the pkgbuild has been updated to use ninja and now should build properly. Let me know if there are any issues.

oh, that's wonderful. Thanks for the update. I appreciate all of your help. I have gone through my pacman logs to see if I could identify a questionable package update with no luck. Let me know if I can be of help, such as with testing. Anything that can be built through this pkgbuild can easily be done in a clean chroot to use best testing practices.

I actually am s0mebodyhelpme on that issue, just fyi.

This is a complicated project with lots of submodules. It could also be an update to one of the submodules that citra uses, which would affect all of the forks. But in that case, we'd have to figure out why it's only happening on arch. This is more than I am capable of investigating. The best bet is to give it time to see what happens in the issue, now that it's been verified by three different people.

It could be a change done by all forks (they tend to commit the same things) or an arch-specific issue. I considered that it could be clang/llvm, but even updating those to version 19 from lordheavy's packages gives another error that occurs earlier on in the build. At any rate, this will probably require some more investigation, @username227.

Edit: it is to be noted that i tried to build on a fork that hadn't been updated in 2 months and still failed. This is puzzling.

Interesting. This actually doesn't surprise me. I tried specifying older builds of certain submodules that I suspected might be causing the problem, but with no luck. It could have been an upstream arch change last week that caused the problem, but the only other thing I can think to do is to timeshift back to my backup two weeks ago and retry, but i'm really not willing to do that.