Skip to content

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

Open
JanDiederich wants to merge 17 commits intocross-rs:mainfrom
JanDiederich:ubuntu24
Open

Updated Docker image to Ubuntu-24.04 and Cargo dependencies#1580
JanDiederich wants to merge 17 commits intocross-rs:mainfrom
JanDiederich:ubuntu24

Conversation

@JanDiederich
Copy link

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?

@JanDiederich JanDiederich requested a review from a team as a code owner October 26, 2024 22:43
@Emilgardis
Copy link
Member

/ci try

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@Emilgardis Emilgardis marked this pull request as draft October 27, 2024 17:52
@JanDiederich
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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

@itpetey
Copy link

itpetey commented Dec 1, 2024

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
Copy link
Author

@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
Copy link
Member

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

@JanDiederich
Copy link
Author

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
Copy link
Member

Emilgardis commented Mar 30, 2025

don't you need libfontconfig1-dev:arm64 ?

also, why install gcc etc again?

@JanDiederich
Copy link
Author

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
Copy link
Author

@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
Copy link
Author

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

@JanDiederich
Copy link
Author

@Emilgardis Any update?

@JanDiederich
Copy link
Author

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
Copy link
Member

Xargo can be dropped, its not relevant anymore

@Emilgardis
Copy link
Member

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
Copy link
Member

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

@JanDiederich
Copy link
Author

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.

@JanDiederich
Copy link
Author

JanDiederich commented Aug 17, 2025

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
Copy link
Member

/ci try

@github-actions

This comment has been minimized.

@Emilgardis
Copy link
Member

#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 :)

@github-actions

This comment has been minimized.

# Install packages
root="root-${arch}"

mkdir -p "${root}"/{bin,etc/dropbear,root,sys,dev,proc,sbin,tmp,usr/{bin,sbin},var/log}
Copy link

Choose a reason for hiding this comment

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

Suggested change
mkdir -p "${root}"/{bin,etc/dropbear,root,sys,dev,proc,sbin,tmp,usr/{bin,sbin},var/log}
mkdir -p "${root}"/{etc/dropbear,root,sys,dev,proc,tmp,usr/{bin,sbin},var/log}

This two should make the ln below fail. Maybe its overall more failsafe to create the symlinks first, to assure no package install or so pre-creates the dirs.

Copy link
Member

Choose a reason for hiding this comment

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

afaik it should work fine, but it's unnecessary.

Copy link

Choose a reason for hiding this comment

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

I know now why it did not fail, but it is not as it was supposed to be, wait.

@MichaIng
Copy link

MichaIng commented Feb 6, 2026

Further things to fix:

  • in android-system.sh: libncurses5 => libncurses6
  • cmake.sh runs rm -rf /var/lib/apt/lists/*, and some Dockerfile's run apt-get install right afterwards, which of course cannot work without lists:
    COPY cmake.sh /
    RUN /cmake.sh
    
    FROM cross-base AS build
    
    RUN apt-get install --assume-yes --no-install-recommends \
        g++-arm-linux-gnueabi \
        gfortran-arm-linux-gnueabi \
        libc6-dev-armel-cross
    
    Removing lists is a reasonable cleanup step, but should be probably done at the very end of each Dockerfile/image generation, not as early as cmake.sh is sometimes called. No idea how this did not cause failures before this PR, since it is unrelated 🤔. To not potentially break something, of course also an additional apt-get update would do.
  • ulimit is not always permitted inside containers. And it can definitely not raise the value without --privileged mode. So if this shall be kept, it must be allowed to fail || true.
  • In crosstool-ng.sh, the last crosstool build fails, but I cannot see any details about why, since silence_stdout ... silences STDOUT 😄: https://github.com/cross-rs/cross/blob/main/docker/crosstool-ng.sh#L101-L102
  • Debian Trixie dropped support for ix86 architecture, so linux-image-6.12.41+deb13-686 does not exist. That is a tricky one 🤔. Probably worth to think about dropping 32-bit x86 support for cross-rs as well? Otherwise some other sources need to be taken. Not sure how this is solved in other non-Debian architectures. Just pull older Debian (Bookworm), if this does not conflict with other scripts?

Comment on lines +280 to +288

mkdir -p "${root}"/{bin,etc/dropbear,root,sys,dev,proc,sbin,tmp,usr/{bin,sbin},var/log}
for deb in "${arch}"/*deb; do
dpkg -x "${deb}" "${root}"/
done
# make libraries and binaries available as usrmerge
for d in lib lib64 bin sbin; do
ln -ns "usr/${d}" "${root}/${d}"
done
Copy link

@MichaIng MichaIng Feb 6, 2026

Choose a reason for hiding this comment

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

It did work now, since /lib and /lib64 were linked. But /bin and /sbin links were put into the previously created /bin and /sbin directories. I was missing the -d flag to assure ln takes the actual directory as link target, instead of putting it inside. It did not cause issues here, but if on actual usage or later on something is looking for an executable in /(s)bin while all of them are in /usr/(s)bin, it might become an issue.

And to prevent any potential package which does not follow usrmerge pre-creates any of the dirs, it is easier to create the symlinks first.

Suggested change
mkdir -p "${root}"/{bin,etc/dropbear,root,sys,dev,proc,sbin,tmp,usr/{bin,sbin},var/log}
for deb in "${arch}"/*deb; do
dpkg -x "${deb}" "${root}"/
done
# make libraries and binaries available as usrmerge
for d in lib lib64 bin sbin; do
ln -ns "usr/${d}" "${root}/${d}"
done
# make libraries and binaries available as usrmerge
for d in lib lib64 bin sbin; do
ln -snd "usr/${d}" "${root}/${d}"
done
mkdir -p "${root}"/{etc/dropbear,root,sys,dev,proc,tmp,usr/{bin,sbin,lib,lib64},var/log}
for deb in "${arch}"/*deb; do
dpkg -x "${deb}" "${root}"/
done

@github-actions

This comment has been minimized.

@Emilgardis
Copy link
Member

/ci try

@github-actions

This comment has been minimized.

repository = "https://github.com/cross-rs/cross"
version = "0.2.5"
edition = "2021"
version = "0.2.6"
Copy link
Member

@Emilgardis Emilgardis Feb 7, 2026

Choose a reason for hiding this comment

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

this should not be bumped in this pr, and if it should be bumped it should be to 0.3.0, I want to do a alpha + rc first though :)

# mipsel was discontinued in trixie, so we have to use bookworm.
kernel='6.*-4kc-malta'
deps=(libcrypt1:"${arch}")
debsource="deb http://http.debian.net/debian/ bookworm main"
Copy link

Choose a reason for hiding this comment

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

http.debian.net redirects to deb.debian.org. And any reason to not use HTTPS here?

Suggested change
debsource="deb http://http.debian.net/debian/ bookworm main"
debsource="deb https://deb.debian.org/debian bookworm main"

Same for the other sources, but everything below bullseye will require archive.debian.org instead.

And for debian-ports (also available at deb.debian.org/debian-ports, a dedicated keyring is needed: https://deb.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/

Comment on lines +284 to +288
if [ -d "usr/${d}" ]; then
ln -nsd "usr/${d}" "${root}/${d}"
else
mkdir -p "${root}/${d}"
fi
Copy link

@MichaIng MichaIng Feb 7, 2026

Choose a reason for hiding this comment

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

The directories are expected to not yet exist here, but they will be created with below package installs (or the mkdir -p call). Even if they remain non-existent, the symlinks do not hurt. This condition needs to be removed, else, as the test shows, it fails again:

Suggested change
if [ -d "usr/${d}" ]; then
ln -nsd "usr/${d}" "${root}/${d}"
else
mkdir -p "${root}/${d}"
fi
ln -nsd "usr/${d}" "${root}/${d}"

Copy link
Member

Choose a reason for hiding this comment

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

Its needed because bookworm/buster/older doesnt have these directories

Copy link

@MichaIng MichaIng Feb 7, 2026

Choose a reason for hiding this comment

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

Bookworm is as well usr-merged, but right everything below no fully. In that case, below:

mkdir -p "${root}"/{etc/dropbear,root,sys,dev,proc,tmp,usr/{bin,sbin},var/log}

=>

mkdir -p "${root}"/{etc/dropbear,root,sys,dev,proc,tmp,usr/{bin,sbin,lib,lib64},var/log}

If there are any issues with package installs (like "file X is already in package Y"), then it would need to be done conditional based on Debian version. But the symlinks must be all created on Bookworm and Trixie, else things fail.

Copy link
Member

Choose a reason for hiding this comment

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

Ah yes, i mixed up the intent and broke what was fixed :D

@github-actions

This comment has been minimized.

@Emilgardis
Copy link
Member

/ci try

@github-actions

This comment has been minimized.

@MichaIng
Copy link

MichaIng commented Feb 8, 2026

Debian ports supports powerpc as well: https://deb.debian.org/debian-ports/
Maybe better/easier than using old Jessie from archive?

A bunch of runs failed with 50x and 403 for network requests, most likely due to some rate limiting. It should be possible to rerun only failed jobs directly in the Actions GUI. It does checkout new code for those, only the code of the workflows themselves remains the same. That should speedup test iterations and reduce concurrent network requests to package servers etc.

@github-actions

This comment has been minimized.

@github-actions
Copy link

github-actions bot commented Feb 8, 2026

Try run for comment

Failed Jobs

List

Successful Jobs

List

Comment on lines 399 to 404
if [[ "${arch}" == "riscv64" ]]; then
# Symlink dynamic loader to /lib/ld-linux-riscv64-lp64d.so.1
mkdir -p "${root}/lib"
ln -s /usr/lib/riscv64-linux-gnu/ld-linux-riscv64-lp64d.so.1 "${root}/lib/ld-linux-riscv64-lp64d.so.1"
fi

Copy link

Choose a reason for hiding this comment

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

Suggested change

This is now redundant (and hence fails) with the usr-merge symlinks being created above already.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[EOL] Ubuntu 20.04 is no longer updated

8 participants