Please update fmt to 9.0.0

[Tachi107]

libfmt 9.0.0 has lots of improvements (more constexpr stuff, improved C++20 compatibility), and updating to it would improve the situation for #1, as it is currently impossible to build Cemu using the system version of libfmt on recent distros.

Cemu is currently using version 7.1.3, released at the end of 2020.

[ArtemisX64]

@Tachi107 fmt 9.0.0 has breaking changes compared to 7.1.3 . It can be ported but won't be easy
For example, many functions are under new namespaces and some functions(mainly used by Cemu) are now deprecated

[Tachi107]

Yeah I know, that's why I opened an issue instead of submitting a PR ;)

[Scrumplex]

vcpkg doesn't offer fmt 9.0.0 yet, despite it being released over a month ago. I assume this is another blocker for the developers of Cemu

[ArtemisX64]

@Scrumplex It does offer it
I think they merged it recently

[Tachi107]

Yes, it was merged 22 days ago, see microsoft/vcpkg#25658

[Exzap]

With port overlays its pretty easy to use any version of the lib we want. The actual issue are the many breaking changes they introduced, so updating our code to support fmt 9.x.x is no longer trivial.

I think it makes more sense to include fmt 7.x.x as a git submodule which avoids the need for vcpkg. In the long term we can then work towards supporting later versions of fmt.

[Tachi107]

The issue is not vcpkg itself, as it is usable on Linux, but the fact that users can't use the system version. This also makes it unlikely for Cemu to be packaged by distros, as they have a policy of not allowing bundled libraries, except for rare cases.

No pressure though, updating the used fmt version is far from the only problem affecting the Linux builds :)

[ReillyBrogan]

If a distribution won't allow Cemu to be packaged without bundling certain libraries (where Cemu depends on a version that's incompatible with the system one) then honestly that distribution shouldn't be packaging Cemu in the first place, or they should be packaging a version of that library co-installable with the official "system" library (such as libfmt-7 which could be installed alongside libfmt).

[Scrumplex]

@Scrumplex It does offer it I think they merged it recently

hmm, the website only shows 8.1.1 though :|

[Tachi107]

@ReillyBrogan

If a distribution won't allow Cemu to be packaged without bundling certain libraries (where Cemu depends on a version that's incompatible with the system one) then honestly that distribution shouldn't be packaging Cemu in the first place, or they should be packaging a version of that library co-installable with the official "system" library (such as libfmt-7 which could be installed alongside libfmt).

There are a lot of pros and cons of the "no bundling" policy (security, reproducibility, size...). Sometimes it is even possible to install different versions of the same library, but you quickly run into issues like "both libfmt-7 and libfmt-9 install /usr/include/fmt/format.h, how can they co-exist?"; you could move the headers to /usr/include/fmt7 and /usr/include/fmt9, but now you broke pretty much every project using the library. It is not that easy.

Anyway, distribution policies are outside of the scope of this issue.

[ReillyBrogan]

There are a lot of pros and cons of the "no bundling" policy (security, reproducibility, size...).

I am well aware, having been substantially involved as a system package and maintainer for a number of years now. That has given me a lot of first-hand experience in how the needs/goals of distributions and the needs/goals of complex applications are often diametrically opposed.

but you quickly run into issues like "both libfmt-7 and libfmt-9 install /usr/include/fmt/format.h, how can they co-exist?

Typically for rolling distributions this is done when libfmt is upgraded from say major version 7 to 8. libfmt will retain the normal paths (like /usr/include/fmt/format.h), while a new package libfmt-7 will be introduced which is patched to change the install directories just enough that there are no conflicts with the libfmt package (such as /usr/include/fmt7/format.h). Then packages that are not yet compatible with major version 8 will receive patches to force it to use the libfmt-7 version of the files. This overlap gives more time to the various packages to fix support for the new major version without breaking users in the process (the libfmt-7 override patch is removed when the package is updated to the new version that works with the libfmt package).

The alternative here is that the distro updates the libfmt package to v8 which breaks the packages not yet compatible with v7 (obviously an unacceptable scenario). The worse alternative is that the distribution holds back the libfmt update until all packages are ready for it (which is obviously an even more unacceptable scenario).

Anyway, distribution policies are outside of the scope of this issue

I will note that you yourself brought up packaging of Cemu with "This also makes it unlikely for Cemu to be packaged by distros". The natural question that brings up is "Is being packaged by distributions an explicit goal of the Cemu Linux port?". I'll open up a separate issue for that discussion however.

[Tachi107]

The alternative here is that the distro updates the libfmt package to v8 which breaks the packages not yet compatible with v7 (obviously an unacceptable scenario). The worse alternative is that the distribution holds back the libfmt update until all packages are ready for it (which is obviously an even more unacceptable scenario).

Yeah in Debian we update libfmt and fill release-critical bugs to all the packages that fail to build with the new release. This also incentivises maintainers to write patches to fix the build failures and submit them upstream.

Anyway, distribution policies are outside of the scope of this issue

I will note that you yourself brought up packaging of Cemu with "This also makes it unlikely for Cemu to be packaged by distros". The natural question that brings up is "Is being packaged by distributions an explicit goal of the Cemu Linux port?". I'll open up a separate issue for that discussion however.

I expressed myself poorly. I meant that it should not be the main focus of the thread. Distribution policies are one of the reason why I reported this, but it is not what the thread is about.

Just curious, on what distro do you work?

[ReillyBrogan]

Yeah in Debian we update libfmt and fill release-critical bugs to all the packages that fail to build with the new release. This also incentivises maintainers to write patches to fix the build failures and submit them upstream.

And it still means that for users of that distro that Cemu is likely going to be broken until those patches are created because the new version of the library probably breaks ABI compatibility (otherwise Cemu would have likely built against it).

Just curious, on what distro do you work?

Solus Linux now, but I'm also currently involved in the still-nascent SerpentOS.

[Tachi107]

And it still means that for users of that distro that Cemu is likely going to be broken until those patches are created because the new version of the library probably breaks ABI compatibility (otherwise Cemu would have likely built against it).

No, Cemu is not going to be broken. The only thing that gets replaced are the development headers, shared libraries are versioned (a compiled executable doesn't link to libfmt.so, it links to libfmt.so.7). This means that the package can't be updated until the bug is fixed, but current builds will continue to work. With regards to shared libraries and ABI Debian's process is pretty solid.

Solus Linux now, but I'm also currently involved in the still-nascent SerpentOS.

Oh, cool :)

[Exzap]

Closing this because of our stance in regards to #78.

Currently, the officially encouraged way of building Cemu for development is with vcpkg which we have bundled with the fmt version that works. If thats not possible for whatever reason and system libraries have to be used (pull request for that is pending) then we can solve the original issue by using fmt as a git submodule. I rather not we swap out library versions and potentially introduce new bugs when we still have so many problems to solve.

[Tachi107]

@Exzap you should close this as "wontfix", not "completed"