Updated Docker image to Ubuntu-24.04 and Cargo dependencies #1580

JanDiederich · 2024-10-26T22:43:02Z

There were attempts to update to Ubuntu 22 (#973), and then Ubuntu 24, but that seems to have stopped? Also the dependencies were outdated.

So I updated them, but I can't get it running. I tried to build the Docker image for ARM64 Linux, but it stops in an endless loop. The command line is cargo build-docker-image aarch64_be-unknown-linux-gnu-cross --tag local.
In crosstool-ng.sh:

    download() {
        # timeout is a command, not a built-in, so it won't
        # work with any bash functions: must call a command.
        timeout "${timeout}" \
            su "${username}" -c \
            "STOP=${step} CT_DEBUG_CT_SAVE_STEPS=1 ${crosstooldir}/bin/ct-ng build.${nproc}"
    }

    while silence_stdout download; [ $? -eq 124 ]; do
        # Indicates a timeout, repeat the command.
        sleep "${sleep}"
    done

Please, can anyone give me a hint how to fix that?

Emilgardis · 2024-10-27T08:18:13Z

/ci try

JanDiederich · 2024-10-30T20:32:23Z

Looking at the died down predecessor #973 I don't expect any help soon. On the other hand: This project is super famous and used by many, many people.
If you added a donate button I would donate a little bit. Maybe others too? Maybe even if the single tips are small, they sum up to something bigger and were enough of a motivation?

Emilgardis · 2024-10-30T21:45:46Z

Thank you for the consideration, I'd rather get help with contributions like this rather than money <3 I don't think a way to donate would motivate me, but maybe it could motivate other invited maintainers? I have no clue :3

I'll look into the issue you reported, but try setting VERBOSE=1 in the dockerfile to see if there's an error message, we're silencing stdout

JanDiederich · 2024-12-01T16:19:35Z

VERBOSE=1 didn't help, but I could get it a bit further in the compiling, so I get now the following error in my build process when I use the updated "cross":

LC_ALL="C" PATH="/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin" VSLANG="1033" "cc" "-Wl,--version-script=/tmp/rustceDa4y3/list" "-Wl,--no-undefined-version" "/tmp/rustceDa4y3/symbols.o" "/target/aarch64-unknown-linux-gnu/release/deps/zune_jpeg-83beae640ba15514.zune_jpeg.21f0ac8659d152a4-cgu.0.rcgu.o" "/target/aarch64-unknown-linux-gnu/release/deps/zune_jpeg-83beae640ba15514.zune_jpeg.21f0ac8659d152a4-cgu.1.rcgu.o" "/tar ...

Note how it is filled with nightly-x86_64-unknown-linux-gnu instead of ...aarch64..., how can I fix that?

Emilgardis · 2024-12-01T21:33:38Z

nightly-x86_64-unknown-linux-gnu is the correct toolchain to use though, the target may be aarch64, but the toolchain runs on x86_64

petehayes102 · 2024-12-01T23:25:27Z

I managed to get all the way to testing the targets before bombing: https://github.com/petehayes102/cross/actions/runs/12102553312.

You can see my commits on top of your original one: https://github.com/petehayes102/cross/commits/trying/. I messed up this branch so it says its miles ahead of main, though that's just a dodgy rebase!

JanDiederich · 2025-03-30T17:25:26Z

@petehayes102:
I got sidetracked with other projects, but I continued trying to get it to work. So I continued based on your work. Big thanks for that.
So far I changed only my own code. I compile in cross with: cargo build-docker-image aarch64_be-unknown-linux-gnu-cross --tag local. My Dockerfile uses:

FROM ghcr.io/cross-rs/aarch64_be-unknown-linux-gnu-cross:local
ARG DEBIAN_FRONTEND=noninteractive
RUN dpkg --add-architecture arm64
RUN apt-get install -y \
  gcc-aarch64-linux-gnu \
  g++-aarch64-linux-gnu \
  binutils-aarch64-linux-gnu \
  libfontconfig1-dev

I had to configure all my libraries which used some CPU specific SIMD code in their defaults to use other libraries / "vendor" feature, etc.. Then, when I cross-compile my project, I get a lot of this messages: Relocations in generic ELF (EM: 183). Which means that the compiler or linker used is for the wrong architecture.

Any ideas how to solve that?

Emilgardis · 2025-03-30T18:05:40Z

I'd guess gcc-aarch64-linux-gnu is not correct for be

JanDiederich · 2025-03-30T21:15:51Z

I'd guess gcc-aarch64-linux-gnu is not correct for be

Ups. Yes, you were right, I was mixing be and le. Fixed that. Now it's cargo build-docker-image aarch64-unknown-linux-gnu --tag local on the cross side.
And in my project I tried this Dockerfile:

FROM ghcr.io/cross-rs/aarch64-unknown-linux-gnu:local
ARG DEBIAN_FRONTEND=noninteractive
RUN dpkg --add-architecture arm64
RUN echo -e "Types: deb\n\
URIs: http://ports.ubuntu.com/ubuntu-ports\n\
Suites: noble\n\
Components: main universe\n\
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg\n\
Enabled: yes" >> "/etc/apt/sources.list.d/ubuntu.sources"

RUN apt-get update -o APT::Architecture="arm64" -o APT::Architectures="arm64"; exit 0
RUN apt-get install -y \
  gcc-aarch64-linux-gnu \
  g++-aarch64-linux-gnu \
  binutils-aarch64-linux-gnu \
  libfontconfig1-dev

But I always get the same error lines at the end:

note: /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libfreetype.so when searching for -lfreetype
          /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libfreetype.a when searching for -lfreetype
          /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: cannot find -lfreetype: No such file or directory
          /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libfreetype.so when searching for -lfreetype
          /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 when searching for libgcc_s.so.1
          collect2: error: ld returned 1 exit status

Emilgardis · 2025-03-30T22:27:40Z

don't you need libfontconfig1-dev:arm64 ?

also, why install gcc etc again?

JanDiederich · 2025-03-31T22:06:30Z

don't you need libfontconfig1-dev:arm64 ?
also, why install gcc etc again?

Failed attempts to solve dependency problems. When I append ":arm64" the installation failed.
When adding arm64 I can get only something like this:

#9 0.487 The following packages have unmet dependencies:
#9 0.523  adduser : Depends: passwd but it is not going to be installed
#9 0.523  autoconf : Depends: perl (> 5.005) but it is not going to be installed
#9 0.523             Depends: m4 (>= 1.4.13) but it is not going to be installed
#9 0.523             Depends: debianutils (>= 1.8) but it is not going to be installed
#9 0.523  bsdextrautils : Depends: libsmartcols1 (>= 2.39.1) but it is not going to be installed
#9 0.523  g++-13-aarch64-linux-gnu:amd64 : Depends: libstdc++-13-dev-arm64-cross:amd64 (>= 13) but it is not installable
   ... and so on and on ...

For me it seems it runs like this:

Install "package:arm64". Solve dependency "y".
Try to find "y"... Without ":arm64", therefore trying to install amd64.
And then fails because "amd64" is of course incompatible to "arm64".

To solve this I tried this in the Dockerfile:

# Disable all non-arm64 sources
RUN sed -i -e 's/Enabled: yes/Enabled: no/g' /etc/apt/sources.list.d/ubuntu.sources

# Add arm64 sources as the only valid sources
RUN echo -e "Types: deb\n\
URIs: http://ports.ubuntu.com/ubuntu-ports\n\
Suites: noble\n\
Components: main universe\n\
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg\n\
Enabled: yes" >> "/etc/apt/sources.list.d/ubuntu.sources"

It doesn't seem to help at all.

JanDiederich · 2025-04-02T20:06:08Z

@Emilgardis Regarding the package installation problems, do you have any idea how this problem happens?
I get this:

debianutils : Conflicts: debianutils:amd64
debianutils:amd64 : Conflicts: debianutils but 5.17build1 is to be installed

when I try to install the debianutils:arm64 package.
Should it be ":amd64", while the other packages stay ":arm64"?
I'm confused?!

JanDiederich · 2025-06-10T21:17:12Z

@Emilgardis Is there a way I can persuade someone to solve this? Maybe with a donation after all?

JanDiederich · 2025-08-07T22:40:49Z

@Emilgardis Any update?

JanDiederich · 2025-08-15T15:31:57Z

I updated some crates and Rust and now "xargo" isn't compiling anymore, which is for a long time now in maintenance only mode. "Xargo" doesn't seem to easy to fix too. This seems like a never-ending story.

Emilgardis · 2025-08-15T15:38:11Z

Xargo can be dropped, its not relevant anymore

Emilgardis · 2025-08-15T15:40:11Z

Also sorry for not seeing your earlier comments! I have completely missed them. Ill take a look at what you've said and give a response if needed

Emilgardis · 2025-08-15T21:13:50Z

Not sure how to solve the issues you're seeing, also not sure why it happens :/

JanDiederich · 2025-08-16T01:37:22Z

Xargo can be dropped, its not relevant anymore

Big thanks. I commented it out everywhere, that already helped a lot. I could get it to compile with the latest Rust and the latest packages.

It seems smoothed out, but I still struggle with the part where I use it. I can't get it to compile my project due to basic conflicts. Where I need the debianutils in the arm64 version, but the system refuses to install them because they conflict with the already installed amd64 version. I tried removing the essentials packages dash and bash, so I could remove debianutils:amd64 and then reinstall the arm64 versions, but that doesn't work, because after I removed the amd64 packages, the image was so broken, no installation of anything was possible anymore.

…hains - which is 1.88.0

JanDiederich · 2025-08-17T00:52:07Z

I think (but I'm not sure) my PR now works for the most part, and the problems I have are personal package installation problems, which have nothing to do with my PR branch.
So I rebased my PR and fixed the CI chain. The only thing I find irritating was Owo-Colors, which got its Stdin removed in its Stream, so I commented OwoColors-Stdin everywhere out. Because, if I understand it correctly, Owo-Colors is used to colorize the terminal output, why should it have StdIn colorization anyway?

Edit: I see, someone else already made a PR with an Owo-Colors correction: #1611, interesting. But I see no discussion if that solution is accepted or not?

Emilgardis · 2025-08-17T09:36:03Z

/ci try

Emilgardis · 2025-08-17T09:43:58Z

#1611 is fine, the issue was how to resolve the old dependency without introducing multiple versions of crates.

[..] if I understand it correctly, Owo-Colors is used to colorize the terminal output, why should it have StdIn colorization anyway?

I think that's right, the impl can be removed :)

…d64 repositories, removed commented out xargo code in Dockerfiles

JanDiederich · 2025-08-19T21:20:17Z

#1611 is fine, the issue was how to resolve the old dependency without introducing multiple versions of crates.

[..] if I understand it correctly, Owo-Colors is used to colorize the terminal output, why should it have StdIn colorization anyway?

I think that's right, the impl can be removed :)

So should I just remove the commented out code completely?

Anyway: I cracked it! 😄!

The problem is with Ubuntu 24 and how it treats missing packages for requested architectures (apt-get install).
If you explicitly specify blaBla:arm64 and it searches in http://archive.ubuntu.com/ubuntu and http://ports.ubuntu.com/ubuntu-ports and it finds it only in ...-ports, it will tell you: There is no package and it can't download anything!

So, you must add the architectures to each source (in ubuntu.sources), like this:

URIs: http://ports.ubuntu.com/ubuntu-ports
Architectures: arm64
...
URIs: http://archive.ubuntu.com/ubuntu
Architectures: amd64 i386

It saves you also time, because it won't look in the wrong places where the packages don't exist anyway.

So, instead of adding this to all my Dockerfiles, I added this to the end of each of cross's aarch64 Dockerfile:

COPY ubuntu.sources /etc/apt/sources.list.d/

This is a prepared ubuntu.sources with the arm64 architecture added to "ports". I have no knowledge of all the other 50 (?) architectures this project provides and how the Debian sources configurations for them look, so I limited this to aarch64 / arm64.

petehayes102 · 2025-08-19T23:52:23Z

Well done @JanDiederich!! Thank you for persisting with this. Great job!

Emilgardis · 2025-08-20T13:45:43Z

I'm sorry, I should have realized this earlier.. That's essentially what I do here: #751 (comment) with sed 's/^deb http/deb [arch=arm64] http/' -i '/etc/apt/sources.list'

JanDiederich · 2025-08-20T21:28:37Z

I'm sorry, I should have realized this earlier.. That's essentially what I do here: #751 (comment) with sed 's/^deb http/deb [arch=arm64] http/' -i '/etc/apt/sources.list'

Maybe, but that's outdated now. With Ubuntu 24 the sources.list got deprecated, replaced by ubuntu.sources, with the new syntax. So I still think copying a template is a good idea. Or some much more sophisticated sed!?

Edit: Oh, and maybe the old sources.list support could be dropped completely, since the standard Ubuntu 20 support was dropped finally, a few month ago.

Compilation and running

After a long time I got my first cross-compilation running again, under my always up-to-date Ubuntu 24 and installed it on my always up-to-date Raspberry Pi OS and... It didn't work. This was the first time I had a glibc version conflict, I solved it by manually compiling and installing the specific glibc version 2.39 on my Raspberry Pi - which supports out-of-the-box only glibc 2.36.

Like this:

Compilation and installation

sudo apt install build-essential wget tar
sudo apt install gawk bison

wget http://ftp.gnu.org/gnu/libc/glibc-2.39.tar.gz
tar -xvzf glibc-2.39.tar.gz
cd glibc-2.39
mkdir build
cd build

../configure --prefix=/opt/glibc-2.39
make -j$(nproc)
sudo make install

Run program

/opt/glibc-2.39/lib/ld-linux-aarch64.so.1 --library-path /opt/glibc-2.39/lib:/usr/lib/aarch64-linux-gnu ./your_program

I write this as a help for others, and also because I saw a max_glibc_version() function in the target_info.sh script, maybe that's a point where a manipulation should be done and explicitly limit this to a specific glibc version (optionally of course)?

JanDiederich · 2025-08-21T19:19:01Z

@Emilgardis As I wrote myself, I neither know all supported architectures, nor am I a Linux professional. But I think most people here are also no general experts in this fields. But they know their stuff and have an idea how to get it working.

So my suggestion is: You merge this into an "edge" branch, release that, and let the people Pull-Request this into a polished final version.

Emilgardis · 2025-08-22T05:10:36Z

I dont think an edge branch approach is necessary, if the image doesnt build then the previous build will be used.

I'll have a closer look at this PR, probably submit some patches myself and then merge. Thank you!

/ci try

Emilgardis · 2025-08-22T05:23:26Z

Ill reiterate here also why I'm considering merging this pr now before releasing 0.3.0. The ubuntu version we're currently using on main is not maintained now, and trying to patch the tools and repos to make it work is a bigger pain for maintaining the project, therefore the approach of updating the base version of ubuntu is much more attractive to further the development and hopefully then finally push 0.3.0 of cross once all images we want are compliant

github-actions · 2025-08-22T06:19:35Z

Try run for comment

try / conclusion - ❌

Failed Jobs

List

Successful Jobs

List

JanDiederich · 2025-08-29T21:38:23Z

Ill reiterate here also why I'm considering merging this pr now before releasing 0.3.0. The ubuntu version we're currently using on main is not maintained now, and trying to patch the tools and repos to make it work is a bigger pain for maintaining the project, therefore the approach of updating the base version of ubuntu is much more attractive to further the development and hopefully then finally push 0.3.0 of cross once all images we want are compliant

Well, I'm all for it.

JanDiederich requested a review from a team as a code owner October 26, 2024 22:43

This comment has been minimized.

Sign in to view

Emilgardis marked this pull request as draft October 27, 2024 17:52

seriousben mentioned this pull request Dec 18, 2024

chore(CI): testing releasing building on PRs tensorlakeai/indexify#1114

Merged

3 tasks

gatlinnewhouse mentioned this pull request Apr 15, 2025

Use native ssl on pi coffee-and-telesense/meshtastic-telemetry-daemon-rs#22

Closed

Jan Diederich and others added 5 commits August 16, 2025 23:57

Updated Docker image to Ubuntu-24.04 and Cargo dependencies

ff4feb9

WIP

4d63049

WIP

0e7077f

Readd submodule

9e2a03f

Bugfixes for Ubuntu 24

ec85b34

Jan Diederich added 8 commits August 17, 2025 00:51

Set the minimum Rust version to one supporting Rust 2024 and if-let-c…

e519f97

…hains - which is 1.88.0

Setting rustc consistently everywhere to 1.89.0

9672ea7

Fixed clippy 1.89.0 findings

1b151dd

Fixed Cargo fmt

f7187ab

Using Rust 1.89.0 in ci.yml and weekly.yml

9cf1fd7

Allowing new licenses which came with crate updates

9d67c45

Fixed Owo-Color having Stdin removed in latest version

aaf0ede

Fixed local.rs formatting

25b317e

This comment has been minimized.

Sign in to view

Jan Diederich added 3 commits August 19, 2025 02:47

"FROM ubuntu:24.04 as" to "FROM ubuntu:24.04 AS"

84a9258

Added "ubuntu.sources" with the correct configured arm64, i386 and am…

ea1399b

…d64 repositories, removed commented out xargo code in Dockerfiles

"ubuntu.sources" missed an ending newline

4c79fd6

JanDiederich changed the title ~~Draft: Updated Docker image to Ubuntu-24.04 and Cargo dependencies~~ Updated Docker image to Ubuntu-24.04 and Cargo dependencies Aug 21, 2025

JanDiederich marked this pull request as ready for review August 21, 2025 19:12

JanDiederich mentioned this pull request Aug 22, 2025

Update images to Ubuntu 22.04 LTS #973

Closed

This comment has been minimized.

Sign in to view

Emilgardis mentioned this pull request Aug 28, 2025

Xargo breaks new image building. #1701

Closed

11 tasks

Updated Docker image to Ubuntu-24.04 and Cargo dependencies #1580

Are you sure you want to change the base?

Updated Docker image to Ubuntu-24.04 and Cargo dependencies #1580

Conversation

JanDiederich commented Oct 26, 2024

Uh oh!

Emilgardis commented Oct 27, 2024

Uh oh!

This comment has been minimized.

This comment has been minimized.

JanDiederich commented Oct 30, 2024

Uh oh!

Emilgardis commented Oct 30, 2024

Uh oh!

JanDiederich commented Dec 1, 2024

Uh oh!

Emilgardis commented Dec 1, 2024

Uh oh!

petehayes102 commented Dec 1, 2024

Uh oh!

JanDiederich commented Mar 30, 2025

Uh oh!

Emilgardis commented Mar 30, 2025

Uh oh!

JanDiederich commented Mar 30, 2025

Uh oh!

Emilgardis commented Mar 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JanDiederich commented Mar 31, 2025

Uh oh!

JanDiederich commented Apr 2, 2025

Uh oh!

JanDiederich commented Jun 10, 2025

Uh oh!

JanDiederich commented Aug 7, 2025

Uh oh!

JanDiederich commented Aug 15, 2025

Uh oh!

Emilgardis commented Aug 15, 2025

Uh oh!

Emilgardis commented Aug 15, 2025

Uh oh!

Emilgardis commented Aug 15, 2025

Uh oh!

JanDiederich commented Aug 16, 2025

Uh oh!

JanDiederich commented Aug 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Emilgardis commented Aug 17, 2025

Uh oh!

This comment has been minimized.

Emilgardis commented Aug 17, 2025

Uh oh!

This comment has been minimized.

JanDiederich commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Anyway: I cracked it! 😄!

Uh oh!

petehayes102 commented Aug 19, 2025

Uh oh!

Emilgardis commented Aug 20, 2025

Uh oh!

JanDiederich commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Compilation and running

Compilation and installation

Run program

Uh oh!

JanDiederich commented Aug 21, 2025

Uh oh!

Emilgardis commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

Emilgardis commented Aug 22, 2025

Uh oh!

github-actions bot commented Aug 22, 2025

Try run for comment

Emilgardis commented Mar 30, 2025 •

edited

Loading

JanDiederich commented Aug 17, 2025 •

edited

Loading

JanDiederich commented Aug 19, 2025 •

edited

Loading

JanDiederich commented Aug 20, 2025 •

edited

Loading

Emilgardis commented Aug 22, 2025 •

edited

Loading