I am not sure why Gentoo is being referred to when talking about binary distributions. The point of Gentoo is that everything is compiled from source on the target system.

The PowerShell I am using on Alpine 3.17 comes from the distribution

alpine3:~$ apk list | grep powershell
powershell-7.2.7-r0 x86_64 {powershell} (MIT) [installed]

On Alpine the standard NEEDED bindings are to the platform specific libc

alpine3:~$ ldd /bin/bash
	/lib/ld-musl-x86_64.so.1 (0x7fda89964000)
	libreadline.so.8 => /usr/lib/libreadline.so.8 (0x7fda8984a000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fda89964000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7fda897ed000)
alpine3:~$ ldd /usr/bin/pwsh
	/lib/ld-musl-x86_64.so.1 (0x7ff0c6bc3000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7ff0c6961000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7ff0c6943000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7ff0c6bc3000)

and on ARM64

alpine3:~$ ldd /bin/bash
	/lib/ld-musl-aarch64.so.1 (0x7f820a5000)
	libreadline.so.8 => /usr/lib/libreadline.so.8 (0x7f81f51000)
	libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0x7f820a5000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7f81ee0000)
alpine3:~$ ldd /usr/bin/pwsh
	/lib/ld-musl-aarch64.so.1 (0x7f9cbea000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f9c964000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f9c933000)
	libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0x7f9cbea000)

In summary, please continue to support alpine as a first-class distribution for PowerShell even if you do other builds for musl libc. Below is the 7.3.3 alpine build direct from this project.

alpine3:~$ ldd /opt/microsoft/powershell/7/pwsh
        /lib/ld-musl-x86_64.so.1 (0x7fa208f71000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fa208d0d000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fa208cef000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fa208f71000)

@rhubarb-geek-nz

I am not sure why Gentoo is being referred to when talking about binary distributions. The point of Gentoo is that everything is compiled from source on the target system.

Well this is off-topic but I guess as a Gentoo developer I have to address this.
Claim that "everything is compiled from source on the target system" is definitely not the point of Gentoo. What about cross-compialation, customized image creation and binpkgs?
Gentoo is about choice of tools, distribution way and system usage.
Maybe because our tools are "raw" or complicated to some it comes off as "there is only one way: compile everything from source".

The new Gentoo .NET team wants to package pwsh from-source build but also keep the binary package (pwsh-bin) of the previous maintainer.

In summary, please continue to support alpine as a first-class distribution for PowerShell even if you do other builds for musl libc.

Yea, I guess the "instead" goes too far.
I think releases specific to Alpine can co-exist with generic musl libc releases.

My biggest concern is that, YES, on Alpine having libc.musl-x86_64.so.1 is correct but it might not exists on other Linux distros and in that case the normal libc link should be used.

... but also keep the binary package (pwsh-bin) of the previous maintainer.

@xgqt Can you tell the previous maintainer that the file attributes are wrong after installation of pwsh-bin on Gentoo? Many of the dll and so files have the owner-execute bit set, the only file that needs the execute bit set is pwsh itself. This is due to the wrong permissions in the original tars but could be fixed in the ebuild. #18899

... but also keep the binary package (pwsh-bin) of the previous maintainer.

@xgqt Can you tell the previous maintainer that the file attributes are wrong after installation of pwsh-bin on Gentoo? Many of the dll and so files have the owner-execute bit set, the only file that needs the execute bit set is pwsh itself. This is due to the wrong permissions in the original tars but could be fixed in the ebuild. #18899

I can fix that in ::gentoo-dotnet-2023 overlay, which will be later used in ::gentoo.
See the full plan of migration here: https://bugs.gentoo.org/900597
I will fix that on the said overlay when I have time but you are free to open a PR to it: https://gitlab.com/xgqt/gentoo-dotnet-2023

900597 – Gentoo Dotnet Project: introduce the dotnet-pkg eclass and packages depending on it

GitLab

Maciej Barć / gentoo-dotnet-2023 · GitLab

Experimental Gentoo Linux for packages related to the dotnet SDK.

... but also keep the binary package (pwsh-bin) of the previous maintainer.

@xgqt Can you tell the previous maintainer that the file attributes are wrong after installation of pwsh-bin on Gentoo? Many of the dll and so files have the owner-execute bit set, the only file that needs the execute bit set is pwsh itself. This is due to the wrong permissions in the original tars but could be fixed in the ebuild. #18899

I can fix that in ::gentoo-dotnet-2023 overlay, which will be later used in ::gentoo. See the full plan of migration here: https://bugs.gentoo.org/900597 I will fix that on the said overlay when I have time but you are free to open a PR to it: https://gitlab.com/xgqt/gentoo-dotnet-2023

900597 – Gentoo Dotnet Project: introduce the dotnet-pkg eclass and packages depending on it

GitLab**Maciej Barć / gentoo-dotnet-2023 · GitLab**Experimental Gentoo Linux for packages related to the dotnet SDK.

Ok, this is fixed in the overlay now.
It's not critical so I will not push it into ::gentoo.

900597 – Gentoo Dotnet Project: introduce the dotnet-pkg eclass and packages depending on it

GitLab

Maciej Barć / gentoo-dotnet-2023 · GitLab

Experimental Gentoo Linux for packages related to the dotnet SDK.

@xgqt Hi, can you print what you think the NEEDED should look like? I had a look at openwrt and that is like

$ ldd /bin/busybox 
	/lib/ld-musl-aarch64.so.1 (0xffff8b2c1000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xffff8b29f000)
	libc.so => /lib/ld-musl-aarch64.so.1 (0xffff8b2c1000)

So the /lib/ld loader is architecture specific and libc.so points back to the same /lib/ld shared library. On the file system it is

$ ls -ld /lib/libc.so
-rwxr-xr-x    1 root     root        517115 Feb 15  2021 /lib/libc.so
$ ls -ld /lib/ld-musl-aarch64.so.1 
lrwxrwxrwx    1 root     root             7 Feb 15  2021 /lib/ld-musl-aarch64.so.1 -> libc.so

This is how it looks in my Gentoo chroot with musl libc as system libc:

The libc.so => ... here is absolutely correct, the thing Im complaining about is
libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0x7f820a5000)
or libc.musl-x86_64.so.1 => not found in case of .NET SDK.

I think the issue in https://bugs.gentoo.org/894760#c3 is that either that version or musl or that profile does not install the /lib/ld-musl-x86_64.so.1 link.

894760 – dev-dotnet/dotnet-sdk-bin-3.1.423-r4 installs files with unresolved SONAME dependencies (MUSL-CLANG-SYSTEM)