.NET SDK uses wrong libc name on musl libc

[xgqt]

Describe the bug

On a Gentoo system built with musl libc the library libc.musl-x86_64.so.1 is inaccessible.

Expectations

.NET SDK links to a more widely known musl library name.

Further technical details

musl version is: 1.2.3-r7

See also https://bugs.gentoo.org/894760

[xgqt]

This also propagates to programs built with such dotnet exe.

See: https://bugs.gentoo.org/894758

[xgqt]

It is possible to build applications with this seemingly broken dotnet since it ALSO links to a libc library: libc.so.6 => /lib64/libc.so.6 (0x00007f16a4d49000).

The .NET SDK musl version was probably supposed to be used on a glibc Linux system but for a musl packaging?
Is this correct? How should the musl version be used on Linux systems without glibc?

[am11]

.NET SDK links to a more widely known musl library name.

We don't explicitly specify the libc name or path, we are using the system defaults (Alpine Linux):

# use gcc to compile a hello world app
$ echo "int main(){}" | gcc -xc -
# inspect the executable
$ ldd ./a.out 
     /lib/ld-musl-x86_64.so.1 (0x7f15b41a7000)
     libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f15b41a7000)
$ readelf -a ./a.out | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libc.musl-x86_64.so.1]

# compare with dotnet executable

$ ldd $(command -v dotnet)
        /lib/ld-musl-x86_64.so.1 (0x7f088e769000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f088e507000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f088e4e9000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f088e769000)
$ readelf -a $(command -v dotnet) | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.musl-x86_64.so.1]

Do you have a suggestion to improve DT_NEEDED at build time? If you built everything on gentoo-musl (.NET Runtime + SDK) then it should use whatever defaults were there on the build machine.

Alternatively, you can create a libc.musl-x86_64.so.1 -> /usr/lib/libc.so symlink on your system if it is missing it.

Another alternative is to patch the ELF after the fact:

# Prerequisite: emerge equivalent of 'apk add patchelf'

$ patchelf --replace-needed libc.musl-x86_64.so.1 libc.so $(command -v dotnet)
# or patch all ELF files under install dir
$ find /usr/share/dotnet/ -exec file {} \; | grep ELF | \
     while IFS=: read name rest; do patchelf --replace-needed libc.musl-x86_64.so.1 libc.so $name; done
# (and ~/.nuget dir if needed)

# verify desired results
$ ldd $(command -v dotnet)
        /lib/ld-musl-x86_64.so.1 (0x7f2186a5d000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f21867f9000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f21867db000)
        libc.so => /lib/ld-musl-x86_64.so.1 (0x7f2186a5d000)
$ readelf -a $(command -v dotnet) | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

[xgqt]

@am11 thank you for your quick response.
Unfortunately you will have to take my words with a grain of salt because I am not a toolchain expert.

Do you have a suggestion to improve DT_NEEDED at build time? If you built everything on gentoo-musl (.NET Runtime + SDK) then it should use whatever defaults were there on the build machine.

Currently we struggle with building .NET SDK from source under Portage mainly because the network restriction and huge build size, see: gentoo/gentoo#21112

So we are talking about binary distributed by Microsoft / .NET project now only.

Alternatively, you can create a libc.musl-x86_64.so.1 -> /usr/lib/libc.so symlink on your system if it is missing it.

I hope a person form Gentoo Toolchain Project or one of musl maintainers in Gentoo could comment on that.

Another alternative is to patch the ELF after the fact:

I think this is what we will have to do.
Thanks for the snippet :D

[xgqt]

Im worried that subsequent application builds will also want to link to "wrong" musl libc name.
Do you know if this is taken from some place defined by .NET SDK?
Im taking about this issue: https://bugs.gentoo.org/894758

[danmoseley]

Cc @richlander

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

On a Gentoo system built with musl libc the library libc.musl-x86_64.so.1 is inaccessible.

Expectations

.NET SDK links to a more widely known musl library name.

Further technical details

musl version is: 1.2.3-r7

See also https://bugs.gentoo.org/894760

Author:	xgqt
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[am11]

@xgqt, I am not sure if that issue was just a lint warning or the app actually failed to run? In another issue (https://bugs.gentoo.org/894760#c3), I see this link:

        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f16a5287000)

which suggests that the link was resolved on gentoo. Try running that app.

[xgqt]

@xgqt, I am not sure if that issue was just a lint warning or the app actually failed to run? In another issue (https://bugs.gentoo.org/894760#c3), I see this link:

        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f16a5287000)

which suggests that the link was resolved on gentoo. Try running that app.

It must run since it can compile .NET applications,
in https://bugs.gentoo.org/894758 it compiles csharp-language-server.

[xgqt]

@xgqt, I am not sure if that issue was just a lint warning or the app actually failed to run? In another issue (https://bugs.gentoo.org/894760#c3), I see this link:

        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f16a5287000)

which suggests that the link was resolved on gentoo. Try running that app.

It must run since it can compile .NET applications, in https://bugs.gentoo.org/894758 it compiles csharp-language-server.

This is the logfile: https://894758.bugs.gentoo.org/attachment.cgi?id=851776

And quoting the build process:

>>> Unpacking source...
>>> Unpacking csharp-language-server-0.5.7.tar.gz to /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work
>>> Unpacking csharp-language-server-0.5.7-prebuilt.tar.xz to /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work
>>> Source unpacked in /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work
>>> Preparing source in /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7 ...
 * Running dotnet restore /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src --source /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/nuget_packages -p:TargetFramework=net6.0 ...
=  Determining projects to restore...
=========  Restored /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer.Tests/CSharpLanguageServer.Tests.fsproj (in 475 ms).
  Restored /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer/CSharpLanguageServer.fsproj (in 474 ms).
 [ ok ]
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7 ...
 * Running dotnet build --configuration Debug --no-restore --no-self-contained --nologo --output /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7_net6.0_Debug/csharp-language-server -maxCpuCount:1 -p:TargetFramework=net6.0 /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src ...
==  CSharpLanguageServer -> /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7_net6.0_Debug/csharp-language-server/CSharpLanguageServer.dll
  CSharpLanguageServer -> /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7_net6.0_Debug/csharp-language-server/CSharpLanguageServer.dll
/var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer.Tests/DocumentationTests.fs(102,1): warning FS0988: Main module of program is empty: nothing will happen when it is run [/var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer.Tests/CSharpLanguageServer.Tests.fsproj]
=  CSharpLanguageServer.Tests -> /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7_net6.0_Debug/csharp-language-server/CSharpLanguageServer.Tests.dll

Build succeeded.

/var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer.Tests/DocumentationTests.fs(102,1): warning FS0988: Main module of program is empty: nothing will happen when it is run [/var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/work/csharp-language-server-0.5.7/src/CSharpLanguageServer.Tests/CSharpLanguageServer.Tests.fsproj]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:07.48
 [ ok ]
>>> Source compiled.
>>> Test phase [not enabled]: dev-dotnet/csharp-language-server-0.5.7

>>> Install dev-dotnet/csharp-language-server-0.5.7 into /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/image
>>> Completed installing dev-dotnet/csharp-language-server-0.5.7 into /var/tmp/portage/dev-dotnet/csharp-language-server-0.5.7/image

 * Final size of build directory: 1084284 KiB ( 1.0 GiB)
 * Final size of installed tree:    57832 KiB (56.4 MiB)

 * QA Notice: Unresolved soname dependencies:
 * 
 * 	/usr/share/csharp-language-server/CSharpLanguageServer: libc.musl-x86_64.so.1
 * 
strip: x86_64-gentoo-linux-musl-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   /usr/share/csharp-language-server/CSharpLanguageServer
>>> Done.

[am11]

Yup, I was referring to that QA Notice, if the app runs, that means dynamic linker is happy. You can ignore the lint / QA warning.

[xgqt]

Yup, I was referring to that QA Notice, if the app runs, that means dynamic linker is happy. You can ignore the lint / QA warning.

Well, not really, "we" can not ignore it,
in Gentoo we care very much to have no QA warnings, mislinked or missing libraries.

But yes, this is not a critical issue in term of that the app can run.

BUT it might be producing "garbage" applications --> #83779 (comment)