yuzu icon indicating copy to clipboard operation
yuzu copied to clipboard

Yuzu no longer builds in Linux due to fmt

Open Shoegzer opened this issue 1 year ago • 14 comments

Yuzu is now failing to build, throwing the following compile-time exception:

CMake Error at CMakeLists.txt:159 (find_package):
  Could not find a package configuration file provided by "fmt" (requested
  version 8.0.1) with any of the following names:

    fmtConfig.cmake
    fmt-config.cmake

  Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
  to a directory containing one of the above files.  If "fmt" provides a
  separate development package or SDK, be sure it has been installed.

Testing info:

  • CPU: Intel i7-10870H
  • OS: Linux Mint 20.3 / kernel 5.15
  • Compiler: gcc-11.1.0
  • Commit tested: 97729fd8e9c2f8cabc626ab03a666c9428e01c5e
  • Last known good commit: 4ae75bec50d2d629c0c3d36b5f0b11d3e4e39703
  • Full compile log: here

Shoegzer avatar Jul 23 '22 22:07 Shoegzer

Set -DYUZU_USE_BUNDLED_VCPKG=ON or build fmt from source and provide the path.

lat9nq avatar Jul 23 '22 22:07 lat9nq

Cannot reproduce and I am not using vcpkg. Make sure to have fmt installed on your system

xcfrg avatar Jul 23 '22 22:07 xcfrg

Thanks. @lat9nq I tried with -DYUZU_USE_BUNDLED_VCPKG=ON and it got further but eventually received the following:

CMake Error at externals/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
  Could not find a package configuration file provided by "Catch2" (requested
  version 2.13.7) with any of the following names:

    Catch2Config.cmake
    catch2-config.cmake

  Add the installation prefix of "Catch2" to CMAKE_PREFIX_PATH or set
  "Catch2_DIR" to a directory containing one of the above files.  If "Catch2"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:171 (find_package)

Shoegzer avatar Jul 23 '22 22:07 Shoegzer

Set -DYUZU_TESTS=0 if you don't care about the ctests.

lat9nq avatar Jul 23 '22 23:07 lat9nq

Thanks. It got even further now but the build is still failing, with errors like this:

../src/audio_core/renderer/voice/voice_info.cpp:89:15: error: conversion from ‘int’ to ‘u16’ {aka ‘short unsigned int’} may change value [-Werror=conversion]

Here's a new compile log.

Shoegzer avatar Jul 23 '22 23:07 Shoegzer

Update: Thinking this may be compiler related but not entirely sure (it had been building okay with gcc-11.1 before). @lat9nq any thoughts with this one? I can try to get a bisect if you think it might help. Thanks again for any thoughts.

Shoegzer avatar Jul 24 '22 18:07 Shoegzer

@OlegAckbar have you done a bisect on this or can you determine an earlier point when compilation worked for you in Linux (at least after 4ae75bec50d2d629c0c3d36b5f0b11d3e4e39703 which as noted above is the last time it worked here). I'll attempt a bisect myself if not, just wanted to be sure you hadn't first.

Shoegzer avatar Jul 28 '22 18:07 Shoegzer

It gets even more obscure for me, as I build with -w in CFLAGS:

In file included from …/externals/dynarmic/src/dynarmic/ir/microinstruction.cpp:6:
In file included from …/externals/dynarmic/src/dynarmic/../dynarmic/ir/microinstruction.h:10:
In file included from …/externals/dynarmic/externals/mcl/src/../include/mcl/container/intrusive_list.hpp:12:
In file included from …/externals/dynarmic/externals/mcl/src/../include/mcl/assert.hpp:10:
[   58s] In file included from /usr/include/fmt/format.h:48:
[   58s] /usr/include/fmt/core.h:1732:3: error: static_assert failed due to requirement 'formattable' "Cannot format an argument. To make type T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt"

Same with clang-14 and gcc-12. FMT is 9.0.0.

v-fox avatar Jul 29 '22 02:07 v-fox

Interesting, and it's consistent. What is your OS? At least with more people having build issues with the latest commits, someone should be able to track it down. I've not had any success bisecting it myself, I think that's at least partially due to the switch from conan to vcpkg. As I mentioned, 4ae75bec50d2d629c0c3d36b5f0b11d3e4e39703 builds fine on an old source tree taken from when it was a new commit. However a git checkout of the same commit from the latest source tree now fails with errors such as:

../src/core/arm/dynarmic/arm_dynarmic_32.cpp:155:12: error: ‘struct Dynarmic::A32::UserConfig’ has no member named ‘far_code_offset’

Shoegzer avatar Jul 29 '22 21:07 Shoegzer

@Shoegzer Ensure you have a compatible version of dynarmic checked out when using old commits. There is API and behavior incompability between versions, and mismatching versions have no guarantee of being functional.


Speaking of fmt: Do note that fmt 8.1.0 is what yuzu is currently building with on github CI, and 9.0.0 is a major version update that introduces API breakage.


For the record dynarmic version 6.2.3 is compatible with fmt 9.0.0.

merryhime avatar Jul 29 '22 21:07 merryhime

Thanks @merryhime. I guess bisecting this will be more tricky than I had initially thought but I should have expected that. Do you know of an easy way to bisect while preserving the older dynarmic from externals?

Also, where did you see that I'm using fmt 9.0.0? I'm using 8.1.1, at least from what the log I posted above shows:

fmt[core]:x64-linux -> 8.1.1#1

That said, 8.1.1 is still one minor rev. beyond what you said yuzu builds with on CI - could that matter?

Shoegzer avatar Jul 29 '22 22:07 Shoegzer

  1. You would probably want to execute git submodule update --init --recursive before testing after each bisect step

  2. v-fox above was using 9.0.0.

  3. 8.1.1 should be fine

merryhime avatar Jul 29 '22 22:07 merryhime

Thanks @merryhime. Using git submodule update --init --recursive a bisect will complete successfully, however it reports the bad commit as 096366ead51345bcd170e31b6160b14aaf73e996, with a different error as we've been reporting above and in other issue logs. The bisect error is the same as @v1993 reported in the comments section of the PR with the bad commit, but wasn't that fixed before it merged?

Here's the full bisect log.

Also, compiling the latest commit with make rather than ninja (again using gcc-11.1.0) errors with the following:

/home/testing/Desktop/yuzu/src/video_core/command_classes/codecs/codec.cpp:38:5: error: ‘AV_HWDEVICE_TYPE_VULKAN’ was not declared in this scope; did you mean ‘AV_HWDEVICE_TYPE_VDPAU’?

Here's the full build log.

Shoegzer avatar Aug 02 '22 22:08 Shoegzer

Update: linux builds are still failing after using the updated fmt 9.0.0 from vcpkg per #8730:

fmt[core]:x64-linux -> 9.0.0 -- /home/testing/Desktop/yuzu/yuzu/externals/vcpkg/buildtrees/versioning_/versions/fmt/9268e89cdadcbb0a54357f47b343004200970a02

Again the main error seems to be:

In file included from ../src/audio_core/renderer/behavior/behavior_info.cpp:5:
../src/./audio_core/renderer/behavior/behavior_info.h:21:12: note: ‘struct AudioCore::AudioRenderer::BehaviorInfo::ErrorInfo’ declared here
   21 |     struct ErrorInfo {
      |            ^~~~~~~~~
[1212/1614] Building CXX object src/audio_core/CMakeFiles/audio_core.dir/renderer/voice/voice_info.cpp.o
FAILED: src/audio_core/CMakeFiles/audio_core.dir/renderer/voice/voice_info.cpp.o

Updated full build log

Shoegzer avatar Aug 08 '22 03:08 Shoegzer

Update: Upgraded the test system to Linux Mint 21, which is based on Ubuntu 22.02 and uses gcc-11.2.0. This has resolved the above build issue, even though the root cause remains unknown. I'll close this now but anyone who continues to have issues please let me know and I can reopen, or post to #8634.

Shoegzer avatar Aug 11 '22 00:08 Shoegzer