Open omajid opened 1 week ago
Tagging subscribers to this area: @vitek-karas, @agocke, @vsadov See info in area-owners.md if you want to be subscribed.
The managed DLL bound to this executable is: 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2'
That is the placeholder that should get replaced by the SDK during build: https://github.com/dotnet/runtime/blob/075b42d9b251ad2d38684c85b7305fbf349630ce/src/native/corehost/corehost.cpp#L39-L40 https://github.com/dotnet/runtime/blob/075b42d9b251ad2d38684c85b7305fbf349630ce/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs#L90-L91
We do explicitly check whether the placeholder value is the same though, so I am confused as to why we don't hit this check: https://github.com/dotnet/runtime/blob/075b42d9b251ad2d38684c85b7305fbf349630ce/src/native/corehost/corehost.cpp#L71-L82
It seems like on those platforms, the crossgen2
executable is somehow (reported as) successfully produced, but without actually updating the placeholder? Do you have a binlog for the build/publish of crossgen2
itself?
Description
I am seeing variants of this error on Fedora ELN and CentOS Stream 10, with .NET 8 and .NET 9.
With .NET 8, I see this when building the VMR:
Trying to trace this shows:
On CentOS Stream 10, the VMR is built successfully, but the produced SDK fails to run with similar symptoms.
Reproduction Steps
On Fedora:
$ fedpkg clone -a dotnet8.0 $ cd dotnet8.0 $ fedpkg --namespace rpms --name dotnet8.0 --release eln mockbuild --no-cleanup-after
Expected behavior
.NET builds
Actual behavior
VMR fails to build, or the generated SDK is broken.
Regression?
Yes.
I don't see this behaviour on Fedora 41, or CentOS Stream 8 or 9.
Known Workarounds
No response
Configuration
$ clang --version clang version 19.1.0 (Fedora 19.1.0-1.eln143) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin Configuration file: /etc/clang/x86_64-redhat-linux-gnu-clang.cfg
Other information
I had to port https://github.com/dotnet/runtime/pull/109198 first, to build against clang 19. But clang 19 is also used on Fedora 41, and that doesn't show the same issue.