[ArPow] Build has a hard dependency on libunwind, which is not available on RHEL 8

[omajid]

I can't build installer commit 28be3e9a006d90d8c6e87d4353b77882829df718 on RHEL 8:

dotnet-28be3e9a006d90d8c6e87d4353b77882829df718-x64-bootstrap/src/source-build-reference-packages.0aba30b468e666bdc3cfc6c36a8b417a0f6fb62a/artifacts/source-build/self/package-cache/runtime.linux-x64.microsoft.netcore.ilasm/6.0.0-rc.2.21459.6/runtimes/linux-x64/native/ilasm: error while loading shared libraries: libunwind-x86_64.so.8: cannot open shared object file: No such file or directory

This SDK prebuilt nuget package has a hard dependency on libunwind, which is not available in RHEL 8.

Is there some way I can rebuild this to avoid this hard dependency?

Is there a longer term fix we can use to avoid depending on libunwind for our bootstrap builds?

[omajid]

I tried replacing runtime.linux-x64.microsoft.netcore.ilasm and runtime.linux-x64.microsoft.netcore.ildasm with versions downloaded from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json but it leads to errors in the build:

dotnet-28be3e9a006d90d8c6e87d4353b77882829df718-x64-bootstrap/src/runtime.826f81a11ad17f415668fe1cb934bdaf00d36ea2/artifacts/source-build/self/package-cache/microsoft.dotnet.compatibility/1.0.0-rc.2.21419.17/build/Microsoft.NET.Compatibility.Common.targets(26,5): error MSB4018: The "Microsoft.DotNet.Compatibility.ValidatePackage" task failed unexpectedly. [dotnet-28be3e9a006d90d8c6e87d4353b77882829df718-x64-bootstrap/src/runtime.826f81a11ad17f415668fe1cb934bdaf00d36ea2/artifacts/source-build/self/src/src/libraries/System.IO.Hashing/src/System.IO.Hashing.csproj]                                                                             
dotnet-28be3e9a006d90d8c6e87d4353b77882829df718-x64-bootstrap/src/runtime.826f81a11ad17f415668fe1cb934bdaf00d36ea2/artifacts/source-build/self/package-cache/microsoft.dotnet.compatibility/1.0.0-rc.2.21419.17/build/Microsoft.NET.Compatibility.Common.targets(26,5): error MSB4018: System.MissingMethodException: Method not found: 'Int32 Microsoft.CodeAnalysis.ISymbol.get_MetadataToken()'. [dotnet-28be3e9a006d90d8c6e87d4353b77882829df718-x64-bootstrap/src/runtime.826f81a11ad17f415668fe1cb934bdaf00d36ea2/artifacts/source-build/self/src/src/libraries/System.IO.Hashing/src/System.IO.Hashing.csproj]  

Is this a known issue? Any idea how to work around this?

[omajid]

Any thoughts, @crummel @dseefeld @lbussell @MichaelSimons ?

[dseefeld]

This SDK has a hard dependency on libunwind, which is not available in RHEL 8.

Is there some way I can rebuild this to avoid this hard dependency?

Is there a longer term fix we can use to avoid depending on libunwind for our bootstrap builds?

We don't have bootstrapping figured out here since there is only one build (i.e. no production build to generate the tarball). I think we need a way to build without previously source-built packages for an initial bootstrap build that will generate previously source-built packages for subsequent builds. I'll investigate and report back here.

[omajid]

Any idea how to work around this?

Adding /p:EnablePackageValidation=false to runtime's SourceBuild.props seems to have done the trick.

Thanks, @tmds for the idea!

[dseefeld]

Looking at this closer, it appears that we should be able to bootstrap off of previously source-built packages. The problem here is that the current version of previously source-built packages wasn't built with this change in runtime: dotnet/runtime#58911. This should get fixed in the next update of previously source-built packages here: dotnet/installer#12161. I verified that the version of ilasm in this package does not have a hard dependency on libunwind.

[omajid]

@dseefeld Thanks! That wont address the GLIBC ABI change, though, will it? AFAICS, RHEL 7 will remain broken as we discovered in dotnet/installer#12141.

Have you considered whether it might be a good idea to take the previously source-built packages, and replace all the portable bits in it with the real portable bits published on the in-development .NET nuget feeds?

[tmds]

Have you considered whether it might be a good idea to take the previously source-built packages, and replace all the portable bits in it with the real portable bits published on the in-development .NET nuget feeds?

imo that is the way to go, see dotnet/installer#12141 (comment).

[dseefeld]

Have you considered whether it might be a good idea to take the previously source-built packages, and replace all the portable bits in it with the real portable bits published on the in-development .NET nuget feeds?

I see what you're saying. I was originally looking at creating a bootstrap version of previously source-built packages. I'll continue on that. Thanks!