Repository navigation
Is runtime.linux-x64.Microsoft.NETCore.Runtime.ObjWriter necessary for source-build? #69611
Description
This is a new prebuilt in 7.0 that we're seeing being used by coreclr/ILCompiler. Is this a component that needs to be included in source-build? It seems to be related to Native AOT but there's also some notes where it's being used that make it seem testing-related.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
- Status
Activity
jkotas commentedon May 20, 2022
objwriter is not testing related. It needs to be included in source-build, assuming we want NativeAOT packages to be produced by source-build.
crummel commentedon May 20, 2022
I think that means we need to include https://github.com/dotnet/llvm-project in source-build as well, correct?
cc @MichaelSimons
hoyosjs commentedon May 20, 2022
Yes
agocke commentedon May 23, 2022
I think this is an important question:
There have been some other design problems with NativeAOT and the source build restrictions. In particular, NativeAOT uses pre-built static libraries from the runtime to compile packages. If we use the source build version, things break because they reference specific versions of openssl instead of dynamically loading what's available. See #66859. There seem to be some fundamental conflicts between source build and NativeAOT in terms of compilation model.
jkotas commentedon May 23, 2022
Source build today conflates building from a big pile of sources with applying distro specific policies (#66859 is caused by distro specific policy for dynamic linking). It means that the source build produces product with different characteristics than regular build. It is by design.
I do not think that these are fundamental conflicts. #66859 can be fixed by creating .props file with the additional libraries to reference when the distro specific policies are in affect. It is still work that would have to do be done.
jkotas commentedon May 23, 2022
@tmds @omajid Any thoughts about source build and NativeAOT?
omajid commentedon May 24, 2022
I agree with the comment that source-build - as it currently exists - mixes both "build everything from source" as well as "use the common Linux distribution practices" (including dynamic linking). There's no real reason that both have to be tied together. I could see someone using source-build to build on an "old" platform like CentOS 7 (and leave out the distribution policies) to get something close to Microsoft's portable builds of .NET SDK.
The OpenJDK packages in Fedora are actually exploring something like this (build from source, but violate distro policies and bundle everything), and there's a long discussion thread about that here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IR5C3YVVABP6LVCXQL3UY5VZPSYWDAF5/. So it's not totally out of the world that source-build could be used this way too.
I would much prefer that the source-build SDK have the same set of (possible) features as the Microsoft-built SDK, including NativeAOT.
Taking a step back, how does NativeAOT deal with bundled vs system libraries (
src/native/external/) like brotli, libunwind and zlib? Could it's OpenSSL component use the same strategy with some tweaks?Is there no way to use an upstream llvm directly? Rebuilding all of llvm, aside from taking a very long time every build, is also duplicating the efforts of each distro's existing llvm packages.
jkotas commentedon May 24, 2022
We are using llvm with custom changes: https://github.com/dotnet/llvm-project/tree/objwriter/12.x. We are building a subset, not the whole thing.
22 remaining items
omajid commentedon Jul 28, 2022
I did some digging and here are the cmake versions I can see that are available in some common distributions:
Edit: script to find these versions
omajid commentedon Jul 29, 2022
In terms of distributions that have cmake older than 3.18, we have:
22.0420.04Are any of these using (or planning to use) source-build to ship .NET at the moment? I don't think so. cc @dotnet/distro-maintainers to correct me if I have it wrong.
For a first attempt, how about we just don't support anything with too old cmake? While it would be ideal to implement things the way @tmds suggested (NativeAOT conditioned on a recent-enough version of cmake), I understand that there are lots of unknowns (eg, what does the final UX look like?) that make it challenging to implement right now.
MichaelSimons commentedon Jul 29, 2022
@omajid, Did you mean to include Ubuntu 20.04 instead of 22.04 in the unsupported cmake like?
omajid commentedon Jul 29, 2022
Yes. Sorry, was a typo.
richlander commentedon Jul 30, 2022
I'm often the person pushing on OS support policies. One of my philosophies is making decisions in terms of an STS/LTS pair. We want to avoid offering support for an STS release and then pulled support for the next LTS release. Customers get wedged that way. Something similar happened with .NET Core 2.2, and that was bad. There's also the question of whether we've spending our time and effort wisely.
We made the decision to not support Windows 7 for .NET 7/8. RHEL 7 feels similar.
Clearly, Red Hat gets to make its own decisions on which RHEL versions to support, however, the overall project doesn't necessarily need to take on the extra burden for that. From what I'm reading, the official policy of the .NET 7 project should be RHEL 8+ in terms of taking on burden and leave RHEL 7 as a topic for RH exclusively.
Is that fair?
Separately, I believe that including Native AOT in source build is a good plan. If there is a reasonable way to split source-build so that Native AOT is included for RHEL 8 and not RHEL 7, I'm neutral on that.
On portable vs distro-specific, I like having both options. I see distro-specific as the "optimized version". For folks like RH, that seems like the virtuous choice. For Microsoft building for "all the Linuxes everywhere", portable seems like the virtuous choice. Going forward, we should enable anyone to build portable as well. Only Microsoft can reasonably do that today, which is NOT a goal, just a point-in-time situation.
mirespace commentedon Aug 1, 2022
Hi all,
sorry for the delay, as I was collecting the info internally.
Thank you @omajid for the versions compilation, and yes, for Ubuntu there are two LTS versions under 3.18 (Bionic 18.04 and Focal 20.04). The following are the current cmake versions included in the latest supported Ubuntu series:
3.10.2-1ubuntu2.18.04.2 | bionic-updates
3.16.3-1ubuntu1 | focal
3.22.1-1ubuntu1 | jammy
3.23.2-1ubuntu1 | kinetic
3.23.3-1ubuntu1 | kinetic-proposed
Which will be the oldest LTS that will include dotnet is still an ongoing internal discussion, taking into account the EOL ( not only the EOSS) for the Extended Security Maintenance period of each Ubuntu series.
@jkoritzinsky About cmake being fetched via clang to get higher versions or any different toolchain where this may occur, I did not find any scenario on our side where this happens that way, as we provide cmake separate from clang and it is not supported at build time to retrieve anything apart from the debs packages in the corresponding Ubuntu series pocket being built (i.e. we cannot grab the 22.04 cmake if we are building on 18.04) nor outside of that pocket neither.
Regarding the use of llvm and trying to summarize what is being discussed (iiuc), the actual situation is that we use llvm package (in combination with cmake, clang and ldc packages) for building dotnet from source. The oldest version of llvm is llvm-10 on Bionic 18.04.
In our case, using vendorized software is always a handicap (and could become a blocker) for pursuing the inclusion of the dotnet package in main pocket, where vendorized code is allowed at building time but not at runtime (i.e. the use of
libunwindwas a clear candidate to move from vendorized code insrc/native/externalto the use of deb libunwind-13 package).crummel commentedon Aug 3, 2022
Corresponding libc versions, thanks for the script @omajid:
So it looks like CentOS Stream 8 would probably be our new least-common-denominator version for the base tarball. Do the Stream versions get updated or should that be pretty stable @omajid?
omajid commentedon Aug 3, 2022
We seem to have switched from a "should source-build support building on old distros where the distro-default cmake is too old?" to "what distros should .NET drop support for?" Or am I mixing up source-build and (Microsoft-build of) .NET here?
Or, to put it another way, are we thinking of moving the minimum requirements to build .NET from source or to run .NET?
Moving the runtime baseline from "minimum of RHEL 7 or equivalent" to something newer would also affect other distributions, like Ubuntu 16.04 (which is currently supported for .NET 6) but wont be if we move the baseline higher.
That's a very good point I hadn't thought of.
The EOL dates are a bit different, though. Windows 7, if I understand correctly was EOL'ed in 2020 so it makes sense to drop that in .NET 7. RHEL 7's similar EOL date is in 2024. It seems a little too early to say ".NET 7 won't run on RHEL 7 at all".
That policy does make a lot of sense. I think there are some practical issues that make it very difficult to run .NET on platforms that are not supported by Microsoft, so I am hesitant to fully agree with this policy at this time.
omajid commentedon Aug 3, 2022
I asked our libc maintainers, and their stance is that glibc is backwards compatible, not forward compatible. If you build against a RHEL 8.x build of glibc (CentOS Stream 8 roughly corresponds to RHEL 8.7 right now), .NET will run against that version of glibc or newer. In other words, building against glibc 2.28 in CentOS Stream 8 today may produce binaries that don't work on RHEL 8.6 or older.
However, this has been the glibc stance since forever. It was also true in the RHEL/CentOS 7 era.
However, I don't think this ever became an issue in CentOS 7, so perhaps it will be the same way in CentOS Stream 8?
MichaelSimons commentedon Aug 19, 2022
This was resolved with dotnet/installer#14314.