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 images to Ubuntu 22.04 LTS #973

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Jules-Bertholet
Copy link
Contributor

No description provided.

@Jules-Bertholet Jules-Bertholet requested a review from a team as a code owner July 27, 2022 11:47
Copy link
Member

@Emilgardis Emilgardis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For changelog, please edit https://github.com/cross-rs/cross/blob/main/.changes/591.json, rename to 591-973.json and change 20.04 to 22.04

@Emilgardis
Copy link
Member

readme table needs to be updated.

You can generate the table with

cargo xtask target-info --tag local (all the images need to be built though beforehand)

@Emilgardis
Copy link
Member

bors try --target linux

bors bot added a commit that referenced this pull request Jul 27, 2022
@bors
Copy link
Contributor

bors bot commented Jul 27, 2022

try

Build failed:

@Alexhuszagh Alexhuszagh added this to the 0.4.0 milestone Jul 27, 2022
@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Jul 27, 2022

Marked this for the 0.4.0 milestone since it updates glibc from 2.21 to 2.35, which isn't supported on any Debian distribution as of yet (even on the unstable release, sid).

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Jul 27, 2022

Looks like the error in the images containing a Linux image for full system emulation have an unrelated error: dropbear-2022.82 has a 520 error right now. We might need to switch to another mirror if this stays for a while. A mirror exists if needed.

@Alexhuszagh
Copy link
Contributor

Now that the mirror issues have been fixed...
bors try

bors bot added a commit that referenced this pull request Jul 28, 2022
@bors
Copy link
Contributor

bors bot commented Jul 28, 2022

try

Build failed:

@Emilgardis
Copy link
Member

seems bzip2 is no longer in default installation

@Alexhuszagh
Copy link
Contributor

seems bzip2 is no longer in default installation

That should probably be done explicitly too, since if it's already installed, we can just purge it later.

@Alexhuszagh
Copy link
Contributor

Looks like ncurses-base is no longer a valid package or has no installation candidate: all the linux-image.sh scripts are failing with:

apt-get -d --no-install-recommends download libcrypt1:mips64el busybox:mips64el dropbear-bin:mips64el libtommath1:mips64el libtomcrypt1:mips64el libgmp10:mips64el libc6:mips64el linux-image-5.10.0-16-5kc-malta:mips64el ncurses-base zlib1g:mips64el
#22 20.92 E: Can't find a source to download version '6.3-2' of 'ncurses-base:amd64'

@Alexhuszagh
Copy link
Contributor

Looks like ncurses-base is no longer a valid package or has no installation candidate: all the linux-image.sh scripts are failing with:

apt-get -d --no-install-recommends download libcrypt1:mips64el busybox:mips64el dropbear-bin:mips64el libtommath1:mips64el libtomcrypt1:mips64el libgmp10:mips64el libc6:mips64el linux-image-5.10.0-16-5kc-malta:mips64el ncurses-base zlib1g:mips64el
#22 20.92 E: Can't find a source to download version '6.3-2' of 'ncurses-base:amd64'

Oh, the issue is Ubuntu 22.04 added the package ncurses-base, which has version 6.3-2, which is higher than the ncurses-base in bullseye (6.2+20201114-2). We should also be using bookworm or sid for this upgrade as well, since Ubuntu 22.04 is based off of those versions. We also might need to choose an exact installation candidate, similar to how we do so for conflicting packages on amd64 in linux-image.sh.

@flxo
Copy link
Contributor

flxo commented Nov 11, 2022

Is there anything I can help here?

In the meantime bindgen removed support for ancient clang versions. The clang version in 18.04 is considered ancient.
As a result bindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgrade clang in a custom Dockerfile which is required anyways to install the bindgen requirements.

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Nov 11, 2022

Is there anything I can help here?

In the meantime bindgen removed support for ancient clang versions. The clang version in 18.04 is considered ancient. As a result bindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgrade clang in a custom Dockerfile which is required anyways to install the bindgen requirements.

We use 20.04 on the latest mains and are working on a 0.3.0 release currently. I believe those should still work with bindgen. We'd like ideally to have a release on 20.04 before migrating to 22.04, personally, and I'd like a few bug fixes in the meantime. I'll test this later today with a more recent build.

@flxo
Copy link
Contributor

flxo commented Nov 12, 2022

Is there anything I can help here?
In the meantime bindgen removed support for ancient clang versions. The clang version in 18.04 is considered ancient. As a result bindgen (>=0.60.0) doesn't work in any of those images out of the box. Probably a solution would be to upgrade clang in a custom Dockerfile which is required anyways to install the bindgen requirements.

We use 20.04 on the latest mains and are working on a 0.3.0 release currently. I believe those should still work with bindgen. We'd like ideally to have a release on 20.04 before migrating to 22.04, personally, and I'd like a few bug fixes in the meantime. I'll test this later today with a more recent build.

Thanks. I didn't know that there's 20.04 in between. Haven't tried but it's very likely this works.

Any plans to include the bindgen dependencies by default? I have multiple projects with a Cross.toml and Dockerfiles just for adding the biindgen dependencies.

@Emilgardis
Copy link
Member

Any plans to include the bindgen dependencies by default? I have multiple projects with a Cross.toml and Dockerfiles just for adding the biindgen dependencies.

Not currently, the clang deps take up a lot of space.

You can skip the additional Dockerfiles and only use a Cross.toml (or even just Cargo.toml like this)

# Cross.toml

[target.TARGET]
pre-build = ["apt-get update && apt-get install --assume-yes --no-install-recommends libclang-3.9-dev clang-3.9"]

@ShayBox
Copy link

ShayBox commented Mar 2, 2023

What's the ETA on this change? currently unable to compile anything using libssl as Ubuntu 20.04 only provides libssl1 while every distro now uses libssl3, and Ubuntu 22.04 doesn't have an official package for libssl1.

@Emilgardis
Copy link
Member

What's the ETA on this change?

there is no ETA on 0.4.0, we still have to do 0.3.0 which needs on other changes. development has slowed down a bit due to availability, but any help is greatly appreciated

tesaguri added a commit to tesaguri/pipitor that referenced this pull request Jul 25, 2023
We preferred dynamic linking because that makes it easy for end users to
upgrade OpenSSL (potentially with security fixes) without reinstalling
the app.

When cross-compiling, however, we use a container based on Ubuntu 20.04,
which does not have `libssl3` package, making the release artifact
depend on OpenSSL 1.1.1, which will reach EOL at 2013-09-11
(<https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/>). See also
<cross-rs/cross#973> for current status of the
container image.

This commit aims at working around the problem by statically linking
against OpenSSL when cross compiling, so that the end user does not
need to install OpenSSL 1.1.1.
tesaguri added a commit to tesaguri/pipitor that referenced this pull request Jul 25, 2023
We preferred dynamic linking because that makes it easy for end users to
upgrade OpenSSL (potentially with security fixes) without reinstalling
the app.

When cross-compiling, however, we use a container based on Ubuntu 20.04,
which does not have `libssl3` package, making the release artifact
depend on OpenSSL 1.1.1, which will reach EOL at 2013-09-11
(<https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/>). See also
<cross-rs/cross#973> for current status of the
container image.

This commit aims at working around the problem by statically linking
against OpenSSL when cross compiling, so that the end user does not
need to install OpenSSL 1.1.1.
github-merge-queue bot pushed a commit to kaskada-ai/kaskada that referenced this pull request Jul 25, 2023
We build our binaries on ubuntu:20 which uses libssl1.1 (through our
direct dependency of `reqwest`). Libssl is dynamically linked and with
systems moving to ubuntu:22 that has libssl3.0 our binary breaks. An
example is Google's Collab.

We also build multiplatform linux docker image using `cross-rs`.
`cross-rs` currently builds for ubuntu:20 on their `master` branch and
there is currently an open PR
(cross-rs/cross#973) to move to ubuntu:22.

The proposed solution with this PR is to enable the feature on `reqwest`
that builds the libssl crate (and the libssl library) statically in the
sparrow binaries rather than relying on dynamic linking to pick the
system's libssl library.

We are *not* moving our CI to use ubuntu:22 until there we have a
solution for building multiarch images on ubuntu:22 (through `cross-rs`
or otherwise). Otherwise, if we move to ubuntu:22 today with out any
other changes our docker image will break on linux on arm (anyone on a
Mac with an M chip running a docker container).




1. sparrow depends on `reqwest` which brings in libssl. 
2. added an `if` condition on the release CI that we missed


I verified that the binaries 

Before: 
```
❯ ldd sparrow-main
	linux-vdso.so.1 (0x00007fff56643000)
	libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f3387ee8000)
	libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f3383e00000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3383a00000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3387ec8000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3384321000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3383c1f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3387fa4000)

```


After 

```
❯ ldd sparrow-main
        linux-vdso.so.1 (0x00007ffc7d3f2000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3989800000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f398d9aa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3989b21000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f398961f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f398d9dd000)
```


The final `release` binary size increases by 2MB 

Before:
 
```
❯ ls -lh sparrow-main
-rwxr-xr-x 2 therapon therapon 85M Jul 24 13:09 sparrow-main

```

After

```
❯ ls -lh sparrow-main             
-rwxr-xr-x 2 therapon therapon 87M Jul 24 13:06 sparrow-main

```
@pvshvp-oss
Copy link

Is there a TODO list on this?

@Dylan-DPC
Copy link
Contributor

I wonder if it's worth going straight to Ubuntu 24.04 LTS now instead of 22.04

@pvshvp-oss
Copy link

pvshvp-oss commented May 15, 2024

I wonder if it's worth going straight to Ubuntu 24.04 LTS now instead of 22.04

On a related note, I think it is totally worth having an Arch Linux image that is automatically periodically updated. It may be burdensome for the team to be on their toes updating for SSL or other things.

@polarathene
Copy link

I've not been keeping up with this project, but didn't it use old versions of Ubuntu for minimizing the glibc version to link against for broader portability?

These days you can use cargo zigbuild to cross compile to targets. It handles the glibc minimal version for you so that you can run on a modern distro release, and you don't have to worry about toolchains for different archs, just add the targets via rustup IIRC.

@Emilgardis
Copy link
Member

Emilgardis commented May 15, 2024

@polarathene yes that was one of the reasons for a older release, but we've moved away from that philosophy.
We also provide zigbuild with target.<target>.zig the only problem with that is cross-compiling with dependencies.

the only todo for this is to release 0.3.0 first @pvshvp-oss

We don't provide ssl in our images (except freebsd) for exactly the reason of having to update, instead you have to manually pull the dependency via something like prebuild

we also have a centos based image, making a archlinux based image shouldn't be too hard: https://github.com/cross-rs/cross/blob/7d75864e7812005156805587838f41eb3b30a270/docker/Dockerfile.native.centos

@13r0ck
Copy link

13r0ck commented Oct 3, 2024

I assume that by now this should be closed in favor of cross using Ubuntu 24.04?

@Emilgardis
Copy link
Member

Emilgardis commented Oct 7, 2024

I'll keep it open, but yes, it would probably make sense to jump directly to 24. I've previously said though that we should release 22.04 first but I think that would not be wise anymore.

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

Successfully merging this pull request may close these issues.

9 participants