Bug 25825

Thank you for the report and poinyers.
--------------------------------------
This is a combined list of all *.so.* things required by the current llvm & clang:
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libclangAST.so.8()(64bit)
libclangBasic.so.8()(64bit)
libclangCodeGen.so.8()(64bit)
libclangCrossTU.so.8()(64bit)
libclangDriver.so.8()(64bit)
libclangFormat.so.8()(64bit)
libclangFrontend.so.8()(64bit)
libclangFrontendTool.so.8()(64bit)
libclangIndex.so.8()(64bit)
libclangLex.so.8()(64bit)
libclangParse.so.8()(64bit)
libclangRewriteFrontend.so.8()(64bit)
libclangRewrite.so.8()(64bit)
libclangSerialization.so.8()(64bit)
libclang.so.8()(64bit)
libclang.so.8(LLVM_8)(64bit)
libclangStaticAnalyzerFrontend.so.8()(64bit)
libclangToolingCore.so.8()(64bit)
libclangTooling.so.8()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libgcc_s.so.1(GCC_3.3)(64bit)
libgcc_s.so.1(GCC_3.4)(64bit)
libLLVM-8.so()(64bit)
libLLVM-8.so(LLVM_8)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3.5)(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.14)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.17)(64bit)
libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
libstdc++.so.6(GLIBCXX_3.4.19)(64bit)
libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
libstdc++.so.6(GLIBCXX_3.4.22)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libtinfo.so.6()(64bit)
libxml2.so.2()(64bit)
libxml2.so.2(LIBXML2_2.4.30)(64bit)
libxml2.so.2(LIBXML2_2.5.2)(64bit)
libxml2.so.2(LIBXML2_2.6.0)(64bit)
 in case the request is covered therein under a different name.

Assigning to akien for 'steam'.

Assignee: bugsquad => rverschelde

Thanks for the report. I'm downloading the Imperator: Rome game to check if it's reproducible with the recently updated Steam runtime in the beta Steam client.

@ Thomas, Thierry: What are your thoughts on packaging LLVM's libc++ and libc++abi?

In this case I'd tend to say the game is badly packaged on Steam if it relies on those libs and doesn't bundle them or link statically, but I guess the trend might continue and those libs might eventually be considered ubiquitous enough not to be bundled by thirdparty distributors.

CC: (none) => thierry.vignaud, tmb

(In reply to Oleg Bosis from comment #0)
> It seems like steam runtime doesn't include these libs and rely on system
> ones. Both these libs are available on most popular distributions (ubuntu,
> arch, fedora, opensuse, ...) but Mageia is missing them.

I actually don't see it packaged in Fedora either.
Their llvm spec file explicitly disables it: https://src.fedoraproject.org/rpms/llvm/blob/master/f/llvm.spec#_197

I tested the game and can confirm the issue. There are many similar reports on the game's Steam discussion forum, and the requirement to install libc++ manually is even listed on a recent GamingOnLinux post: https://www.gamingonlinux.com/articles/imperator-rome-has-a-big-livy-update-released-and-the-free-punic-wars-dlc.15531

That confirms my feeling that the upstream developers are wrong to expect libc++ to be installed out of the box, and they should include it in their own distribution, or ask Valve to package it in the Steam runtime.

Still, if there's no big objection to packaging those libs, I guess we could do it if the llvm maintainer (that would be Thomas) agrees.

Summary: libc++.so.1 and libc++abi.so.1 are missing (required for steam games) => libc++.so.1 and libc++abi.so.1 are missing (required for game Rome: Imperator on Steam)

(In reply to Rémi Verschelde from comment #3)
> (In reply to Oleg Bosis from comment #0)
> > It seems like steam runtime doesn't include these libs and rely on system
> > ones. Both these libs are available on most popular distributions (ubuntu,
> > arch, fedora, opensuse, ...) but Mageia is missing them.
> 
> I actually don't see it packaged in Fedora either.
> Their llvm spec file explicitly disables it:
> https://src.fedoraproject.org/rpms/llvm/blob/master/f/llvm.spec#_197

Fedora has these libs since Fedora 22/24 releases:

http://rpm.pbone.net/index.php3/stat/4/idpl/48613330/dir/fedora_22/com/libcxx-3.8.0-3.fc22.i686.rpm.html
http://rpm.pbone.net/index.php3/stat/4/idpl/48704448/dir/fedora_24/com/libcxxabi-3.8.0-3.fc24.i686.rpm.html

(In reply to Rémi Verschelde from comment #4)

> That confirms my feeling that the upstream developers are wrong to expect
> libc++ to be installed out of the box, and they should include it in their
> own distribution, or ask Valve to package it in the Steam runtime.
I think you're right in global sense but I think I's now becoming a trend. The same Paradox Interactive recently announced new version of their Crusader Kings game (CK3) and I guess there'll be the same issue. Also I've searched my installed steam games and found these libs in use by Aspyr game ports (Civilization 5 & 6). Aspyr packages these libs with games, but there's no any guaranty they won't drop them in future releases.

So the best solution is to package these libs in distro. This would also provide an ability to use them in development projects by software developers and would make Mageia more binary compatible with Fedora and Ubuntu.

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

This bug report still apllyes to both MGA8 & Cauldron. The libs mentioned here are part of clang's c++ standard library implementation and this implementation is not part of Mageia repository yet.

I don't know if it worth to update the report's distro version if nobody plans to fix it and package alternative c++ implementation libraries...

(In reply to Oleg Bosis from comment #8)
> This bug report still apllyes to both MGA8 & Cauldron. The libs mentioned
> here are part of clang's c++ standard library implementation and this
> implementation is not part of Mageia repository yet.
> 
> I don't know if it worth to update the report's distro version if nobody
> plans to fix it and package alternative c++ implementation libraries...

Well, Rémi was waiting for Thomas to agree:
(In reply to Rémi Verschelde from comment #4)
<snip>
> 
> That confirms my feeling that the upstream developers are wrong to expect
> libc++ to be installed out of the box, and they should include it in their
> own distribution, or ask Valve to package it in the Steam runtime.
> 
> Still, if there's no big objection to packaging those libs, I guess we could
> do it if the llvm maintainer (that would be Thomas) agrees.

I'll reassign to him, to increase the chance that he reads this.

Assignee: rverschelde => tmb
Version: 7 => Cauldron
CC: (none) => marja11, rverschelde
Whiteboard: (none) => MGA8TOO

Does this bug still apply?

CC: (none) => micheelsen

libcxx is now imported on cauldron!

List of packages:

lib(64)cxx-devel-17.0.6-3.mga10
lib(64)cxx-static-devel-17.0.6-3.mga10
lib(64)cxx1-17.0.6-3.mga10
lib(64)cxxabi-devel-17.0.6-3.mga10
lib(64)cxxabi-static-devel-17.0.6-3.mga10
lib(64)cxxabi1-17.0.6-3.mga10
lib(64)llvm-unwind-devel-17.0.6-3.mga10
lib(64)llvm-unwind-static-devel-17.0.6-3.mga10
lib(64)unwind1-17.0.6-3.mga10
llvm-libunwind-doc-17.0.6-3.mga10.noarch.rpm

CC: (none) => geiger.david68210
Whiteboard: MGA8TOO => MGA9TOO

It this coming to mga9 to test?

CC: (none) => fri