CrossGen2 musl nupkg embeds the libc host

[ayakael]

Description

CrossGen2 6.0.8 nupkg links to wrong libc on linux-musl-arm64 / linux-musl-arm environment.

Unfortunately it seems that it wasn't fixed here, as to this day the error still occurs.

Reproduction Steps

$ wget 'https://globalcdn.nuget.org/packages/microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg'
$ unzip microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg
$ ldd tools/crossgen2
		/lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xffffb8282000)
	libm.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xffffb825d000)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by tools/crossgen2)

Expected behavior

Should link to ld-linux-musl-aarch64.so.1

Actual behavior

Rather links to ld-linux-aarch64.so.1

Regression?

I've been keeping track of the fix, waiting for it to eventually apply to the crossgen2 nuget packages. It never did.

Known Workarounds

Does not occur when built via source-build on Alpine environment. See package available at via
https://dl-cdn.alpinelinux.org/alpine/edge/community/arm64/dotnet6-bootstrap-artifacts-6.0.108-r2.apk (tar package, available at `./usr/lib/dotnet/artifacts/6.0.108/microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg)

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

CrossGen2 6.0.8 nupkg links to wrong libc on linux-musl-arm64 / linux-musl-arm environment.

Unfortunately it seems that it wasn't fixed here, as to this day the error still occurs.

Reproduction Steps

$ wget 'https://globalcdn.nuget.org/packages/microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg'
$ unzip microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg
$ ldd tools/crossgen2
		/lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xffffb8282000)
	libm.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xffffb825d000)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffb84a3000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by tools/crossgen2)

Expected behavior

Should link to ld-linux-musl-aarch64.so.1

Actual behavior

Rather links to ld-linux-aarch64.so.1

Regression?

I've been keeping track of the fix, waiting for it to eventually apply to the crossgen2 nuget packages. It never did.

Known Workarounds

Does not occur when built via source-build on Alpine environment. See package available at via
https://dl-cdn.alpinelinux.org/alpine/edge/community/arm64/dotnet6-bootstrap-artifacts-6.0.108-r2.apk (tar package, available at `./usr/lib/dotnet/artifacts/6.0.108/microsoft.netcore.app.crossgen2.linux-musl-arm64.6.0.8.nupkg)

Configuration

No response

Other information

No response

Author:	ayakael
Assignees:	-
Labels:	area-Infrastructure-coreclr
Milestone:	-

[hoyosjs]

@mangod9 I haven't tested if this only affects 6.0

[mangod9]

@am11 as fyi. @ayakael looks like this was only fixed in .NET 7. Is the ask to backport to 6?

[am11]

It is fixed in v7:

$ ldd 7.0.0-preview.7.22375.6/tools//crossgen2
	/lib/ld-musl-aarch64.so.1 (0x4000000000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4002572000)
	libz.so.1 => /lib/libz.so.1 (0x4002762000)
	libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0x4000000000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x4002789000)

# vs.

$ ldd 6.0.8/tools/crossgen2
	/lib/ld-linux-aarch64.so.1 (0x4000000000)
	libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0x4000000000)
	libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0x4000000000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40018df000)
	libm.so.6 => /lib/ld-linux-aarch64.so.1 (0x4000000000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x4001acf000)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0x4000000000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by 6.0.8/tools/crossgen2)

so we would need to backport it manually to v6 branch, since in v6, the issue is not related to AOT vs. singlefile but rather the configuration which affects the compile step.

[am11]

@ayakael, if you could apply https://github.com/dotnet/runtime/pull/73986.patch and test whether it fixes the issue in Alpine distro package, that would be great.

[ayakael]

@ayakael, if you could apply https://github.com/dotnet/runtime/pull/73986.patch and test whether it fixes the issue in Alpine distro package, that would be great.

Yup, it works on my side when crossbuilding from x64 to aarch64. Testing armv7 now. Thanks :)

[ayakael]

Is there any way to set a system-level nuget global-packages folder, thus allowing distro maintainer to package nupkgs like Crossgen2? Other frameworks allow this, like pip, and it would allow us more legroom in case of future issues like this.

[hoyosjs]

There's ways to modify that behavior, namely a global nuget config (granted that can be overridden) or an env variable NUGET_PACKAGES. Not sure if I think nupkgs coming from the distro package manager is a good idea - you loose all the ecosystem semantics (resolution of conflicts from msbuild+, etc) once you unpack them. And there's also the question how you deal with a user overriding that. What are you trying to achieve with packaging them? I am not familiar with the bootstrapping story in Alpine, so can't give very informed suggestions.

[am11]

One way is to add a 'package source' entry in the system-level nuget default config /etc/opt/NuGet/NuGetDefaults.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="OfficialDistroPackages" value="/path/to/directory/containing/system-level-*.nupkg-files" />
  </packageSources>
</configuration>

A more versatile way (with degree more complexity) is to host nuget repository for your distro https://docs.microsoft.com/en-us/nuget/hosting-packages/overview, add the feed URL in NuGetDefaults and prepopulate the http-cache (which contains data blobs) with most important packages.