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

Update .NET Linux Build for .NET 9 #91826

Closed
richlander opened this issue Sep 8, 2023 · 13 comments
Closed

Update .NET Linux Build for .NET 9 #91826

richlander opened this issue Sep 8, 2023 · 13 comments

Comments

@richlander
Copy link
Member

richlander commented Sep 8, 2023

Update (2024-07): We decided to keep on targeting Ubuntu 16.04 based on other feedback. Doing so hasn't had any significant drawback and maintains significant compatibility.

We should update the Linux build to use Azure Linux 3.0 and target Ubuntu 18.04 for .NET 9. This plan builds on our successful .NET 8 Linux build project. This is for the Microsoft build. Other builders of .NET 9 can and will make different choices.

For .NET 8, we targeted Ubuntu 16.04, in order to provide broad support for older Linux distributions. We considered targeting Ubuntu 18.04 in that timeframe, but that would have broken compatibility with Amazon Linux 2. Upon the request of Amazon, we chose to support Ubuntu 16.04 to avoid that compatibility break. NET 8 will be the last release to provide glibc compatibility for Amazon Linux 2, such that we can move forward to targeting Ubuntu 18.04. This means that the Linux support matrix for .NET 8 and 9 will be significantly different.

Ubuntu glibc versions:

  • Ubuntu 22.04: 2.35
  • Ubuntu 20.04: 2.31
  • Ubuntu 18.04: 2.27
  • Ubuntu 16.04: 2.23

Here are some other distributions (bolded distro versions are compatible):

  • AlmaLinux 8: 2.28
  • AlmaLinux 9: 2.34
  • Amazon Linux 2023: 2.34
  • Amazon Linux 2: 2.26
  • CentOS 7: 2.17
  • CentOS Stream 9: 2.34
  • Debian 11: 2.31
  • Debian 12: 2.36
  • Arch Linux 20230723.0.166908: 2.37
  • Fedora 37: 2.36
  • Fedora 38: 2.37
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 8, 2023
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Sep 8, 2023
@richlander
Copy link
Member Author

richlander commented Sep 8, 2023

/cc @socketnorm @dotnet/distro-maintainers

@am11
Copy link
Member

am11 commented Sep 9, 2023

The older the libc, the broader the compatibility.

IIUC, this update is desired not because we are actually using anything specific from modern glibc in code, but the reason for update is infrastructure related. In that case:

We are building the official image with older glibc on modern distro. We use debootsrap to create a cross-build environment, select older version of Ubuntu during the setup, and then install headers, dependencies etc. During the runtime build, we use -isystem=/path/to/rootfs/dir. This means that libc and the build dependencies are old in the rootfs environment. As the time is passing by, those old dependencies are getting hard to acquire and pass the security scan.

If that is the whole reason of this update, it is possible to setup rootfs environment with newer version of Ubuntu while keeping libc6 version lower. (apt install libc-bin=2.19-0ubuntu6 libc6=2.19-0ubuntu6 in rootfs). This way we will end up with "old libc and new $everythingElse". Note that we don't "execute" anything in rootfs environment aside from apt install et al. during the creation of docker layer.

If we set it up this way, would this satisfy everyone?

@tmds
Copy link
Member

tmds commented Sep 9, 2023

CentOS Stream 8/RHEL8 have 2.28.

If I recall correctly, we (Red Hat) would like to provide a supported version of .NET during the maintenance support phase of RHEL.
For RHEL8, that is till May 2029. To cover that period, we'll need to build .NET 10 on RHEL8.

cc @omajid

@jkotas jkotas added area-Infrastructure and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Sep 9, 2023
@ghost
Copy link

ghost commented Sep 9, 2023

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

We should update the Linux build to target Ubuntu 20.04 for .NET 9. This is for the Microsoft build. Other builders of .NET 9 may choose to target a slightly different glibc.

Ubuntu 20.04 includes glibc version 2.31. .NET 9 will support distributions with glibc 2.31 or newer. Musl distributions (like Alpine) are unaffected.

This plan builds on our successful .NET 8 Linux build project.

For .NET 8, we targeted Ubuntu 16.04, in order to provide broad support for older Linux distributions. We considered targeting Ubuntu 18.04 in that timeframe, but that would have broken compatibility with Amazon Linux 2. Upon the request of Amazon, we chose to support Ubuntu 16.04 to avoid that compatibility break. NET 8 will be the last release to provide glibc compatibility for Amazon Linux 2, such that we can move forward all the way to Ubuntu 20.04. This means that the Linux support matrix for .NET 8 and 9 will be significantly different.

Ubuntu glibc versions:

  • Ubuntu 22.04: 2.35
  • Ubuntu 20.04: 2.31
  • Ubuntu 18.04: 2.27
  • Ubuntu 16.04: 2.23

Here are some other distributions (bolded distro versions are compatible):

  • AlmaLinux 8: 2.28
  • AlmaLinux 9: 2.34
  • Amazon Linux 2023: 2.34
  • Amazon Linux 2: 2.26
  • CentOS 7: 2.17
  • CentOS Stream 9: 2.34
  • Debian 11: 2.31
  • Debian 12: 2.36
  • Arch Linux 20230723.0.166908: 2.37
  • Fedora 37: 2.36
  • Fedora 38: 2.37
Author: richlander
Assignees: -
Labels:

area-Infrastructure, untriaged, needs-area-label

Milestone: -

@jkoritzinsky
Copy link
Member

@tmds this change in minimum glibc version will only apply to the Microsoft build. RedHat's build should still be able to be built against RHEL8's glibc.

@jkotas
Copy link
Member

jkotas commented Sep 9, 2023

RedHat's build should still be able to be built against RHEL8's glibc.

Agree. It can complicate the RHEL build bootstrapping though.

@tmds
Copy link
Member

tmds commented Sep 10, 2023

Can you use Ubuntu 18.04 for .NET 9?

That will evade the need to bootstrap.

It will also make self-contained apps built using the Microsoft SDK work on RHEL 8 (and RHEL 8 compatible distros).

@normj
Copy link

normj commented Sep 10, 2023

Acknowledging from AWS and we will be encouraging users to migrate to Amazon Linux 2023.

@richlander
Copy link
Member Author

We could target 18.04 instead. There is no pressing reason to move to 20.04. Would that resolve the challenges?

@tmds
Copy link
Member

tmds commented Sep 11, 2023

Yes. If you can use Ubuntu 18.04, that would be preferable.

@richlander
Copy link
Member Author

I updated this doc to Ubuntu 18.04. Sorry for the delay.

sbomer added a commit that referenced this issue May 22, 2024
This updates our linux arm32 build to build against a more recent
glibc that supports _TIME_BITS (which we set to 64).

Since openssl may be using either 32-bit or 64-bit time_t, this
includes detection logic to determine which case we are in, and
avoid passing time values that don't fit in 32 bits to openssl.

The arm build image is updated to the latest version of the
images added in
dotnet/dotnet-buildtools-prereqs-docker#1037.

The helix test images are updated to debian images added in
dotnet/dotnet-buildtools-prereqs-docker#1041.
Additional context:

Additional context:

Reintroduces the fix for Y2038 support on arm32
linux (#102059), which was
reverted due to problems running against openssl built with
_TIME_BITS=32.

Fixes #101444 (both the
originally reported issue, and the test failures mentioned in
#101444 (comment)).

Supports: #91826
steveharter pushed a commit to steveharter/runtime that referenced this issue May 28, 2024
This updates our linux arm32 build to build against a more recent
glibc that supports _TIME_BITS (which we set to 64).

Since openssl may be using either 32-bit or 64-bit time_t, this
includes detection logic to determine which case we are in, and
avoid passing time values that don't fit in 32 bits to openssl.

The arm build image is updated to the latest version of the
images added in
dotnet/dotnet-buildtools-prereqs-docker#1037.

The helix test images are updated to debian images added in
dotnet/dotnet-buildtools-prereqs-docker#1041.
Additional context:

Additional context:

Reintroduces the fix for Y2038 support on arm32
linux (dotnet#102059), which was
reverted due to problems running against openssl built with
_TIME_BITS=32.

Fixes dotnet#101444 (both the
originally reported issue, and the test failures mentioned in
dotnet#101444 (comment)).

Supports: dotnet#91826
Ruihan-Yin pushed a commit to Ruihan-Yin/runtime that referenced this issue May 30, 2024
This updates our linux arm32 build to build against a more recent
glibc that supports _TIME_BITS (which we set to 64).

Since openssl may be using either 32-bit or 64-bit time_t, this
includes detection logic to determine which case we are in, and
avoid passing time values that don't fit in 32 bits to openssl.

The arm build image is updated to the latest version of the
images added in
dotnet/dotnet-buildtools-prereqs-docker#1037.

The helix test images are updated to debian images added in
dotnet/dotnet-buildtools-prereqs-docker#1041.
Additional context:

Additional context:

Reintroduces the fix for Y2038 support on arm32
linux (dotnet#102059), which was
reverted due to problems running against openssl built with
_TIME_BITS=32.

Fixes dotnet#101444 (both the
originally reported issue, and the test failures mentioned in
dotnet#101444 (comment)).

Supports: dotnet#91826
@agocke
Copy link
Member

agocke commented Aug 17, 2024

Closing this. I don't think we're going to change anything unless there's a specific reason.

@agocke agocke closed this as completed Aug 17, 2024
@richlander
Copy link
Member Author

Just in time to create a new one for .NET 10!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

7 participants