-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
How does NativeAOT deal with bundled/system library split? source-build can be built so that it uses the system version of |
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. |
Not required for 7.0: dotnet/source-build#2885 (comment) |
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. |
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). |
* 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>
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? |
#97521 has discussion about the fix |
Yup, this was a mistake, I meant to close #97521 |
- 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
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 A user then has these options:
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 |
Take a look at #97536 . With this change, |
- 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
The last place that needs fixing is: runtime/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj Lines 13 to 14 in 7f02aef
|
Sure, I'll take a closer look. |
I will be looking into this next week. |
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.
The text was updated successfully, but these errors were encountered: