-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Value too large for defined data type when cargo build on armv7 with qemu #8719
Comments
Thanks for the report. I think this is a duplicate of #7451. There is some sort of strange interaction of Linux Large File Support with a 64-bit host and a 32-bit docker image running qemu. There's some more discussion on that issue, but in particular see https://bugs.launchpad.net/qemu/+bug/1805913. I'm not sure there is anything Cargo can do about this. I suspect the underlying problem is that |
Hello all, I have a similar use case i.e. (Qemu userspace emulation for armv7 on x86_64 arch). After chrooting inside the image, i tried building my project repository using that and this was the output.
However, when fetching it manually using As suggested earlier by @ehuss, it seems the issue is still persistent to this date with qemu emulation of armv7. The cargo binaries are definitely not the culprit here, and more likely Internally, there is some incompatiblity going on, even after following the suggestion for building the library with parameters provided by Lastly, for this quick and simple test case, I would prefer to use command EDIT: I also proposed a simple solution for anyone that is currenly facing this problem, and until its resolution. #9545 |
Seems to be broken at the moment: rust-lang/cargo#8719
If someone is coming here and also needs a workaround for a docker build: |
That seems to workaround rust-lang/cargo#8719.
That seems to workaround rust-lang/cargo#8719.
That seems to workaround rust-lang/cargo#8719.
That seems to workaround rust-lang/cargo#8719.
That seems to workaround rust-lang/cargo#8719.
That seems to workaround rust-lang/cargo#8719.
- That avoids bug in cargo/qemu/ext4, see rust-lang/cargo#8719. - Increase swap space to give tmpfs bigger size
- That avoids bug in cargo/qemu/ext4, see rust-lang/cargo#8719. - Increase swap space to give tmpfs bigger size
- That avoids bug in cargo/qemu/ext4, see rust-lang/cargo#8719. - Increase swap space to give tmpfs bigger size
- That avoids bug in cargo/qemu/ext4, see rust-lang/cargo#8719. - Increase swap space to give tmpfs bigger size
If you can't make the above Dockerfile-based workaround, what works as well is using tmpfs for the whole |
While use qemu-arm to run 32-bit shlibsign on 64-bit host[1], there is a potential Linux Large File error ... $ qemu-arm -r 3.2.0 -L path_to/rootfs path_to/rootfs/usr/bin/shlibsign \ -i path_to/rootfs/usr/lib/libfreebl3.so path_to/rootfs/usr/lib/libfreebl3.so: Value too large for defined data type ... To workaround QEMU issue [2], use host shlibsign(native or nativesdk) directly [1] rust-lang/cargo#8719 [2] https://lkml.org/lkml/2018/12/28/461 Signed-off-by: Hongxu Jia <[email protected]>
For me this worked, but I had to install rust within the same RUN layer: RUN --mount=type=tmpfs,target=/root/.cargo curl https://sh.rustup.rs -sSf | bash -s -- -y && pip install cryptography==38.0.1 finally, to activate Buildkit, I had to run
|
I had to adapt this slightly to use a different directory for cargo to get it working with the rust base image to build a rust project.
|
FIXME: Disable armv7, because of cargo bug: rust-lang/cargo#8719
Doesn't the tmpfs workaround hurt caching a lot? Cargo has to download and build everything every time if CARGO_HOME is not stored on the filesystem. |
due to rust-lang/cargo#8719 which itself is an issue with libgit2 DDNet will still be tested on ARM64 (the bullseye ARM64 image)
QEMU has issue for mapping data of inode on a 64 arch to a 32 arch https://gitlab.com/qemu-project/qemu/-/issues/263 rust-lang/cargo#8719
See rust-lang/cargo#8719 Signed-off-by: Mark Sagi-Kazar <[email protected]>
It's a problem with the virtualization layer. The error is not coming from cargo or docker, but from QEMU running 32-bit platforms on 64-bit hosts (I don't mean it's a bug in QEMU though). An alternative workaround could be to run a 32-bit QEMU process if you have a multilib set up. This would mean using the host kernel's 32-bit API, which does not suffer from the conversion problem. |
Since cargo (stable) now supports the sparse registry protocol, the easiest workaround is to set the envinronment variable |
Our arm64 alpine job was taking too long, and it is likely that the host VM was under memory pressure. Ensure the VM has enough swap space to complete the build, and use an improved workaround from madiele/vod2pod-rss.
Our arm64 alpine job was taking too long, and it is likely that the host VM was under memory pressure. Ensure the VM has enough swap space to complete the build, and use an improved workaround from madiele/vod2pod-rss.
@flo-at
Are there similar options for |
For anyone having this issue, in the end I went to the path of making a Dockerfile with multi-stage builds that will cross-compile for all the architectures I need on the architecture of the pipeline agent and scrapped using qemu for the cargo build, I only use it to run apt install and other small stuff at the end. If you project allows for this route, you can follow my Dockerfile as guidance I went form 2+ hours build times to 5-10 minutes build times, it was worth the effort. |
docker run --privileged -itd --network host --mount type=tmpfs,target=/root/.cargo arm32v7/ubuntu |
Problem
Trying to build an app for armv7 in a docker container with qemu.
The current result is explained here with the steps to reproduce it : https://github.com/jdrouet/docker-bug-value-too-long
Steps
Possible Solution(s)
No idea.
Notes
The guys from docker claim it's coming from cargo.
Output of
cargo version
:The one from the docker image rust:1-slim-buster
The text was updated successfully, but these errors were encountered: