Fix singlefilehost build in non-portable mode#42415
Conversation
|
Tagging subscribers to this area: @vitek-karas, @agocke |
|
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley |
|
Should I look into adding a CI configuration that exercises runtime build in non-portable mode to catch such regressions earlier for next time around? |
We're planning to do this with arcade-powered source-build. The plan is end-to-end, even--so it also validates dotnet/installer being able to take in a non-portable RID, etc. There's a bit more info at dotnet/source-build#1722. That said, getting a non-portable config into dotnet/runtime would still be useful in the short term, because we obviously don't have arcade-powered source-build yet. 🙂 |
There was a problem hiding this comment.
A nit - can you please remove this message?
The singilefilehost needs to follow the libraries build in terms of how it links to OpenSSL: if it's a non-portable build, the singlefilehost needs to link to OpenSSL via linker arguments. The installer also needs to have FEATURE_DISTRO_AGNOSTIC_SSL defined just like it is defined for the libraries build. Fixes: dotnet#41768
7b213c3 to
3d325d4
Compare
|
Thanks for the quick review and merging this! |
|
I have noticed that two test legs have failed. I have restarted them. |
|
Hello @janvorli! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Backport dotnet/runtime#42415 and carry it as a patch for now.
Backport dotnet/runtime#42415 and carry it as a patch for now.
The
singlefilehostneeds to follow libraries build in terms of how it links to OpenSSL: if it's a non-portable build, the singlefilehost needs to link to OpenSSL via linker arguments.The installer also needs to have
FEATURE_DISTRO_AGNOSTIC_SSLdefined just like it is defined for the libraries build.Fixes: #41768