https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: games-emulation/ryujinx-1.1.1221 installs files with unresolved SONAME dependencies. Discovered on: amd64 (internal ref: tinderbox_musl) System: MUSL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#MUSL) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#QA0023
Created attachment 888037 [details] build.log build log and emerge --info
Please add this to See Also: https://github.com/dotnet/runtime/issues/83779
Andrew, this is not the problem here, Ago was informed of this and it could be considered lucky that either he looked deeper into the current QA or skipped it here. In this case libc issue is known but we also have some venored glibc libs it seems.
I was thinking the workaround for MUSL would be to run patchelf to fix the sonames. It's ugly but it sounds like it should resolve the issue. If this is acceptable I will make a PR.
(In reply to Andrew Udvare from comment #4) > I was thinking the workaround for MUSL would be to run patchelf to fix the > sonames. It's ugly but it sounds like it should resolve the issue. If this > is acceptable I will make a PR. Dont do anything with "libc.musl-x86_64.so.1" warnings. But there are also "libc.so.6" cases - those most likely point to a vendored, precompiled lib for GLIBC. Notice also that those are for vulkan and SDL. You cna probably link system libs in their places, or maybe remove them? Not sure if .NET FFI can find system ones.
(In reply to Maciej Barć from comment #5) > (In reply to Andrew Udvare from comment #4) > > I was thinking the workaround for MUSL would be to run patchelf to fix the > > sonames. It's ugly but it sounds like it should resolve the issue. If this > > is acceptable I will make a PR. > > Dont do anything with "libc.musl-x86_64.so.1" warnings. > But there are also "libc.so.6" cases - those most likely point to a > vendored, precompiled lib for GLIBC. Notice also that those are for vulkan > and SDL. You cna probably link system libs in their places, or maybe remove > them? Not sure if .NET FFI can find system ones. I think we just remove them but not sure. I would have to test this program actually works on a MUSL system. Not readily available for me at the moment.
(In reply to Andrew Udvare from comment #6) > I think we just remove them but not sure. > > I would have to test this program actually works on a MUSL system. Not > readily available for me at the moment. I doubt you have to have a musl system in this case.
tinderbox_musl has reproduced this issue with version 1.1.1221-r1 - Updating summary.
