Replies: 1 comment 7 replies
-
It seems you're hitting #724 Build-scripts are built and kept even if glibc changes, so a build-script compiled on the host can be carried over to the cross container with a lower glibc, causing #724 Now, for the glibc problem, you can solve this in various ways. the simplest, is using cargo-zigbuild, integrated into our # Cross.toml
[target.i686-unknown-linux-gnu]
zig = "2.20" another way, is piggy-backing on https://github.com/cross-rs/cross-toolchains and creating a image for |
Beta Was this translation helpful? Give feedback.
7 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I am trying to cross compile my application (using
axum
+tokio
) that has a lot of dependencies for thei686-unknown-linux-gnu
target.The table in the overview
README
shows, that the docker container used for the target's cross compilation supports GLIBC2.31
onwardI am targeting a device that has
2.20
on it.I think I should try to build my own docker container that has GLIBC
2.20
installed, but I fear I have a bigger problem that would not be solved by this approach:Testing the compilation with the older image for
i686-unknown-linux-gnu
(ghcr.io/cross-rs/i686-unknown-linux-gnu:0.2.2), that has GLIB version2.23
installed, I get following errors:And many errors like this one:
Does this mean that my dependencies inherently depend on
GLIBC_2.28
and I will not be able to compile my project using these crates for my target?Is there anything I could do to run my software on this target that does not involve not using all dependencies that show errors during the cross compilation?
Reading 90846 gave me some hope that I might be able to circumvent my issue with some kind of compilation parameter to use 'weak symbols', but to be honest I do not understand how to apply this information to my use case at all.
Is there anyone who would point me to the right direction on this issue?
Beta Was this translation helpful? Give feedback.
All reactions