Do not resolve a glibc viewer against musl - #788
Merged
Conversation
Rids yields the framework's own RID first, and the comment there explains why
that matters: on Alpine it is linux-musl-x64, which the package does not ship,
so the probe misses and the caller falls through to the dotnet tool rather than
resolving a glibc build against musl.
The synthesised RID below it then undid exactly that. linux-{arch} is yielded
for any Linux, musl included, and that names the glibc build - so the probe hit
after all and handed back an apphost that cannot start. Inline snapshots
survive it, because the launch failure is swallowed and staging takes over, but
a file snapshot whose resolved tool is the viewer throws out of LaunchProcess.
Stop after the framework's own RID when it names musl. Rids takes the identifier
as an argument now so the rule can be tested from any machine, which matters for
a bug whose only natural home is a container nobody runs the suite in.
The same shape is in DiffEngineViewer's NativeResolver.Rids and is not touched
here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rids yields the framework's own RID first, and the comment there explains why
that matters: on Alpine it is linux-musl-x64, which the package does not ship,
so the probe misses and the caller falls through to the dotnet tool rather than
resolving a glibc build against musl.
The synthesised RID below it then undid exactly that. linux-{arch} is yielded
for any Linux, musl included, and that names the glibc build - so the probe hit
after all and handed back an apphost that cannot start. Inline snapshots
survive it, because the launch failure is swallowed and staging takes over, but
a file snapshot whose resolved tool is the viewer throws out of LaunchProcess.
Stop after the framework's own RID when it names musl. Rids takes the identifier
as an argument now so the rule can be tested from any machine, which matters for
a bug whose only natural home is a container nobody runs the suite in.
The same shape is in DiffEngineViewer's NativeResolver.Rids and is not touched
here.