-
Notifications
You must be signed in to change notification settings - Fork 377
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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
readme table needs to be updated. You can generate the table with
|
bors try --target linux |
tryBuild failed: |
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). |
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. |
Now that the mirror issues have been fixed... |
tryBuild failed: |
seems |
That should probably be done explicitly too, since if it's already installed, we can just purge it later. |
Looks like
|
Oh, the issue is Ubuntu 22.04 added the package |
d0867d5
to
f732517
Compare
Is there anything I can help here? In the meantime |
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 |
Not currently, the clang deps take up a lot of space. You can skip the additional # Cross.toml
[target.TARGET]
pre-build = ["apt-get update && apt-get install --assume-yes --no-install-recommends libclang-3.9-dev clang-3.9"] |
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. |
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 |
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.
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.
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 ```
Is there a TODO list on this? |
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. |
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 |
@polarathene yes that was one of the reasons for a older release, but we've moved away from that philosophy. 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 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 |
I assume that by now this should be closed in favor of cross using Ubuntu 24.04? |
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. |
No description provided.