Skip to content
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

NativeAOT doesn't work with Linux non-portable build #66859

Closed
agocke opened this issue Mar 18, 2022 · 14 comments · Fixed by #97523 or #99148
Closed

NativeAOT doesn't work with Linux non-portable build #66859

agocke opened this issue Mar 18, 2022 · 14 comments · Fixed by #97523 or #99148
Labels
area-NativeAOT-coreclr in-pr There is an active PR which will close this issue when it is merged source-build Issues relating to dotnet/source-build
Milestone

Comments

@agocke
Copy link
Member

agocke commented Mar 18, 2022

The problem is that NativeAOT references OpenSSL in two different ways, depending on whether we're doing a portable build or not.

When portable, the Native AOT runtime uses lazy loading (dlopen) to load the installed OpenSSL shared library. This means that the final linking command for a Native AOT app doesn't need the OpenSSL dev shared library to be passed when linking, since it will not try to statically resolve symbols.

This is not true for non-portable builds. In this case, Native AOT is built directly against OpenSSL headers/SOs. This means that Native AOT apps have to pass the appropriate SO to the linker during final linking of NativeAOT apps.

This means that the linking of Native AOT apps depends on whether it was originally compiled with a portable build. We could also try to remove this difference at the root by choosing one way to reference OpenSSL consistently.

More broadly, the feature of a "non-portable" AOT build is questionable. This would produce a Native AOT compiler which can only compiler for the exact platform (e.g. Ubuntu 22.04) that the compiler was built for. This is generally an anti-pattern in compilers.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Mar 18, 2022
@agocke agocke removed the untriaged New issue has not been triaged by the area owner label Mar 18, 2022
@agocke agocke added this to the 7.0.0 milestone Mar 18, 2022
@omajid
Copy link
Member

omajid commented May 24, 2022

How does NativeAOT deal with bundled/system library split? source-build can be built so that it uses the system version of libunwind or the version included in runtime under src/native/external. Is that something else that needs to be tracked here?

@jkotas
Copy link
Member

jkotas commented Aug 28, 2022

In source build, NativeAOT is built directly against OpenSSL headers/SOs. This means that NativeAOT apps have to pass the appropriate SO to the linker during final linking of NativeAOT apps.

All native dependencies are referenced directly in source build. We would need to do this for icu, gssapi, zlib, brotli, and potentially also libunwind that @omajid mentioned above.

@jkotas
Copy link
Member

jkotas commented Aug 29, 2022

Not required for 7.0: dotnet/source-build#2885 (comment)

@crummel
Copy link
Contributor

crummel commented Sep 26, 2022

I've summarized what I believe to be the current state of play and the agreed-upon solution for NativeAOT in 7.0 in #76206. Please check this out and let me know if you have any concerns.

@jkoritzinsky
Copy link
Member

To expand on this, the flag here is actually controlled by if the build is portable, not necessarily source-build (it's possible to build a non-portable regular build and easier to do locally).

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jan 25, 2024
agocke added a commit to agocke/runtime that referenced this issue Jan 25, 2024
@agocke agocke changed the title NativeAOT Linux source build doesn't work with linking targets NativeAOT doesn't work with Linux non-portable build Jan 25, 2024
agocke added a commit that referenced this issue Jan 25, 2024
* Only skip Native AOT for crossgen in non-portable build

Fixes #66859

* Update src/coreclr/tools/aot/crossgen2/crossgen2_publish.csproj

Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>

---------

Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 25, 2024
@jkotas
Copy link
Member

jkotas commented Jan 25, 2024

We still have TODO comments linked to this issue https://github.com/search?q=repo%3Adotnet%2Fruntime%20https%3A%2F%2Fgh.neting.cc%2Fdotnet%2Fruntime%2Fissues%2F66859&type=code , so I assume this should stay open?

@jkotas
Copy link
Member

jkotas commented Jan 25, 2024

#97521 has discussion about the fix

@jkotas jkotas reopened this Jan 25, 2024
@agocke
Copy link
Member Author

agocke commented Jan 25, 2024

Yup, this was a mistake, I meant to close #97521

jkotas added a commit to jkotas/runtime that referenced this issue Jan 26, 2024
- Add a breadcrumb for non-portable build into the Native AOT runtime pack
- Use the breadcrumb to add system OpenSSL libs to the linker command
  line

Contributes to dotnet#66859
@tmds
Copy link
Member

tmds commented Jan 26, 2024

I think that - thanks to the managed ObjWriter by @filipnavara! - this is the main thing that still needs to be solved to enable NativeAOT for source-build.

We need something that enables the linker flags to be different for non-portable builds.

Based on how we made source-build capable of doing SCD publish, I assume the flags would be stored in a rid-specific pack/package/folder. That is: the flags for portable would be in something linux-x64, and the flags for a distro-specific source-build would be in something fedora.39-x64.

A user then has these options:

  • (using a portable rid for) building a portable NativeAOT app (leveraging nuget.org Microsoft binaries)
  • (using a non-portable rid for) building a non-portable NativeAOT app (using distro binaries)

This first app is meant to work across a range of distros, and the second app is meant to meet the requirements for being included in a distro package (because all binaries used were built from source).

cc @dotnet/distro-maintainers

@jkotas
Copy link
Member

jkotas commented Jan 26, 2024

We need something that enables the linker flags to be different for non-portable build

Take a look at #97536 . With this change, /p:PortableBuild=false build is going to produce native aot packages with distro specific RID. PublishAot with these packages is going to pass additional options to linker to produce distro specific binary.

jkotas added a commit that referenced this issue Feb 2, 2024
- Add a breadcrumb for non-portable build into the Native AOT runtime pack
- Use the breadcrumb to add system OpenSSL libs to the linker command
  line

Contributes to #66859
@jkotas
Copy link
Member

jkotas commented Feb 2, 2024

The last place that needs fixing is:

<!-- Can't use NativeAOT in source build yet https://github.com/dotnet/runtime/issues/66859 -->
<NativeAotSupported Condition="'$(DotNetBuildFromSource)' == 'true'">false</NativeAotSupported>
. We should wait for the LKG SDK to pickup changes from #97536 first.

@jkotas
Copy link
Member

jkotas commented Feb 12, 2024

I am reverting part of the change in #98303 to fix build break in source build. There is a confusion between the portable RID, non-portable RID and host RID.

@tmds Could you please take a look if you get a chance?

@tmds
Copy link
Member

tmds commented Feb 12, 2024

Sure, I'll take a closer look.

@tmds
Copy link
Member

tmds commented Feb 23, 2024

I will be looking into this next week.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-NativeAOT-coreclr in-pr There is an active PR which will close this issue when it is merged source-build Issues relating to dotnet/source-build
Projects
Archived in project
6 participants