-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] source-build: don't skip building Native Aot artifacts. #88520
Changes from 1 commit
f9d2e46
0bd9415
3024212
ebe9520
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -136,6 +136,9 @@ The .NET Foundation licenses this file to you under the MIT license. | |
<LinkerArg Include="-static-pie" Condition="'$(StaticExecutable)' == 'true' and '$(PositionIndependentExecutable)' != 'false'" /> | ||
<LinkerArg Include="-dynamiclib" Condition="'$(_IsApplePlatform)' == 'true' and '$(NativeLib)' == 'Shared'" /> | ||
<LinkerArg Include="-shared" Condition="'$(_IsApplePlatform)' != 'true' and '$(NativeLib)' == 'Shared'" /> | ||
<!-- source-build links directly with openssl (-lssl -lcrypto) --> | ||
<LinkerArg Include="-lssl" /> | ||
<LinkerArg Include="-lcrypto" /> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This relates to #66859. I've unconditionally added these flags because there is no condition that tells us if the build links with OpenSSL (source-build non-portable) or loads it dynamically ( In the latter case the flags are not needed. Perhaps they don't cause issues either (on platforms where .NET dlopens OpenSSL). |
||
<!-- binskim warning BA3001 PIE disabled on executable --> | ||
<LinkerArg Include="-pie -Wl,-pie" Condition="'$(_IsApplePlatform)' != 'true' and '$(NativeLib)' == '' and '$(StaticExecutable)' != 'true' and '$(PositionIndependentExecutable)' != 'false'" /> | ||
<LinkerArg Include="-Wl,-no-pie" Condition="'$(_IsApplePlatform)' != 'true' and '$(NativeLib)' == '' and '$(StaticExecutable)' != 'true' and '$(PositionIndependentExecutable)' == 'false'" /> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that you will want to have libicu in this list as well. Is that correct?
I do not think that we want to pass in these libraries to the linker by default. We will need to have a new property for non-portable build output and set it as necessary.
What do you want the default for
dotnet publish
to be in distro-provideddotnet
? Do you want it to produce the non-portable output default or portable output by default? This is general question for all targets, not specific to native AOT. Does it produce portable or non-portable output today?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the first PropertyGroup, we can explicitly define an internal property:
After that, make decisions based on that property:
Condition="'$(_NonPortableBuild)' == 'true'"
; without locking down to linux.Another problem with the current approach is that it disregards static / customization options: https://github.com/dotnet/runtime/blob/60799cc5705fce35d04612dc24bdba46ed5a4f0e/src/coreclr/nativeaot/docs/compiling.md#using-statically-linked-icu
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since non-portable and portable have different traits, we want this to be a deliberate choice by the user.
Similar to choosing between the .NET bundled runtime packs or the portable Microsoft NuGet packages, the UX for this is the user specify the non-portable rid (instead of the portable rid).
We should then add the linker flags based on the selected runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't need to add it to get this compiled on my machine, and
ldd
doesn't show it on my Fedora .NET.so
files.source-build may be using icu in the same way as the portable builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm taking a look at the packages involved in a native aot publish using the preview 5 SDK.
I see
Microsoft.DotNet.ILCompiler
which is the tooling, andruntime.linux-x64.Microsoft.DotNet.ILCompiler
which contains the runtime.For source-build, the first should be identical to the Microsoft one.
And for the second, we want to produce a non-portable rid package, for example:
runtime.fedora.38-x64.Microsoft.DotNet.ILCompiler
The extra linker flags describe what is in the second package, so we should include them in that package when it gets built from source.
The first package then needs a mechanism to pick those up.
@jkotas does this make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The split between RID neutral and RID specific packages is only a download size optimization. It is not designed to allow composing RID specific packages of different origin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the SDK finds the rid specific package explicitly based on the information from BundledVersions.props which we control for source-build:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and
ILCompilerRuntimeIdentifiers
has hardcoded finite lists of RIDs. What happens for RIDs outside this hardcoded list?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some of the lists it will use the runtime graph to find the most appropriate rid from the finite set.
It's clear some changes are needed for the SDK,
Microsoft.DotNet.ILCompiler
, andruntime.<rid>.Microsoft.DotNet.ILCompiler
to work together when built from source.I'm going to avoid the linker flags issue for now by making the build use the openssl portable
dlopen
when source-build and nativeaot are combined, and see what else comes up.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added 3024212 for this.