Closed ReeseMurdock closed 2 years ago
Hi @Topochicho,
I'm glad that this project is useful.
Caused by: failed to create directory
/.cargo/registry/index/github.com-1ecc6299db9ec823
Interesting, that should not happen. This directory stores the local cache of Cargo's registry index and git checkouts of crates. By default these are stored under $HOME/.cargo
. So I think somehow the HOME
environment variable is not set correctly on WSL2.
I see this when I use Podman (rootless) on my Fedora PC:
$ podman run --rm -it --userns=keep-id -u $(id -u):$(id -g) --entrypoint "bash" libvips-build-win-mxe
kleisauke@d1195f3183c5:~$ echo $HOME
/data
I think probably the most logical option would be to remove this non-root build requirement: https://github.com/libvips/build-win64-mxe/blob/e03a405ae91b0b48b8a9e4f09367a03a60f0bff0/build.sh#L75-L78
And remove the inheritance of the current UID and GID as well: https://github.com/libvips/build-win64-mxe/blob/e03a405ae91b0b48b8a9e4f09367a03a60f0bff0/build.sh#L149
Since these binaries are supposed to be safely buildable by root users as well (MXE's SHA256 checksums for tarballs and disabled network for the build process enforces this). I just did this with commit https://github.com/libvips/build-win64-mxe/commit/025fed291b6710625933e22fde3a6608242758b4. Let me know if this works for you.
This is something like what I have been doing. However, not everyone at my work has admin on their machines, and even fewer have sudo on the Linux machines, so that is a problem. The build will still work if the script is run by a non-admin, but it creates permissions issues with some of the files being owned by root.
I have added 2 lines to the end of build-win64-mxe/build.sh -
A call to change the owner using docker:
docker run --rm -t -u 0 -v $PWD/build:/data --entrypoint /bin/bash libvips-build-win-mxe -c "chown -Rh $(id -u):$(id -g) *"
And a chmod to open permissions:
chmod -Rf 777 *
Unfortunately, not only is this a gross hack, but it is not even a %100 solution. If the Docker instance is stopped for some reason, it leaves the files in a mixed permissions state. I could add these commands to the top of build-win64-mxe/build.sh in addition to the bottom, however I was trying to push this into our automated build system, and it chokes on the files with root permissions before my script even gets called.
However, I also understand that this is not going to be a common problem for most people, so I appreciate you looking at it. I will keep plugging away at it, but if you have any additional suggestions, I would appreciate them.
I could not reproduce the build error with these steps on my Windows PC:
PS> wsl.exe -l -v
NAME STATE VERSION
* docker-desktop Running 2
Ubuntu Running 1
docker-desktop-data Running 2
PS> wsl.exe --set-version Ubuntu 2
Settings
-> Resources
-> WSL Integration
and select Ubuntu
to enable the Docker-WSL integration on. After that, click Apply & Restart
.Build Windows x64 static binaries for libvips on Ubuntu using WSL.
# Upgrade the current packages
$ sudo apt update && sudo apt upgrade
# Verify that Docker is working
$ docker version
# Build Windows binaries (first-time build takes a long time, LLVM and Rust must be built from source)
$ git clone https://github.com/libvips/build-win64-mxe.git
$ cd build-win64-mxe/
$ ./build.sh web x86_64 static
\\wsl$\Ubuntu\home\<username>\build-win64-mxe\build\vips-dev-w64-web-8.12.1-static.zip
.But you're right, somehow this makes the tarball owned by root, I see this:
$ ls -l build/vips-dev-w64-web-8.12.1-static.zip
-rw-r--r-- 1 root root 25083334 Dec 1 13:22 build/vips-dev-w64-web-8.12.1-static.zip
AFAIK, this was not a issue with Podman in rootless mode, let me investigate this further.
Oh, I could reproduce that build error on WSL when the current UID and GID are inherited (-u $(id -u):$(id -g)
). I'm testing this patch now:
diff --git a/build/plugins/llvm-mingw/rust.mk b/build/plugins/llvm-mingw/rust.mk
index 1111111..2222222 100644
--- a/build/plugins/llvm-mingw/rust.mk
+++ b/build/plugins/llvm-mingw/rust.mk
@@ -52,6 +52,10 @@ define $(PKG)_BUILD_$(BUILD)
# that the Rust build is reproducible.
$(eval export MXE_ENABLE_NETWORK := 1)
+ # Ensure that the downloaded build dependencies of Cargo are
+ # stored in the build directory.
+ $(eval export CARGO_HOME := $(BUILD_DIR)/.cargo)
+
# Build Rust
cd '$(BUILD_DIR)' && \
$(PYTHON) $(SOURCE_DIR)/x.py build -j '$(JOBS)' -v
Seems to work! It seems that inheriting the current UID and GID also resolves the ownership issue when building with Docker:
$ ls -l build/vips-dev-w64-web-8.12.1-static.zip
-rw-r--r-- 1 kleisauke kleisauke 25083334 Dec 1 16:07 build/vips-dev-w64-web-8.12.1-static.zip
I'll include this fix in the next version bump cycle (planned for tomorrow).
Excellent! I have already incorporated your patch and pushed it to our automated build system. I will let you know in a few hours how it worked on my end.
The automated build system failed on building/install rust again, although at a different spot. I am rebuilding from scratch, under WSL2/ubuntu, to see if this issue is unique to our build system or something that I am doing wrong.
In case you would like to take a look at the current failure - Due to it's size, I have attached the log file rather that pasting the entire thing: rust_x86_64-pc-linux-gnu.log
But here is what I believe is the relevant portion:
Dist cargo-nightly-x86_64-unknown-linux-gnu running: "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/x86_64-unknown-linux-gnu/stage0-tools-bin/fabricate" "generate" "--image-dir" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/image" "--component-name=cargo" "--rel-manifest-dir=rustlib" "--legacy-manifest-dirs=rustlib,cargo" "--product-name=Rust" "--success-message=cargo installed." "--package-name=cargo-nightly-x86_64-unknown-linux-gnu" "--non-installed-overlay" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/overlay" "--output-dir" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/dist" "--work-dir" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu" finished in 8.771 seconds < Cargo { compiler: Compiler { stage: 2, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } } Install cargo stage2 (Some(TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None })) running: "sh" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/cargo-nightly-x86_64-unknown-linux-gnu/install.sh" "--prefix=/data/mxe/usr/x86_64-pc-linux-gnu" "--sysconfdir=/etc" "--datadir=/data/mxe/usr/x86_64-pc-linux-gnu/share" "--docdir=/data/mxe/usr/x86_64-pc-linux-gnu/share/doc/rust" "--bindir=/data/mxe/usr/x86_64-pc-linux-gnu/bin" "--libdir=/data/mxe/usr/x86_64-pc-linux-gnu/lib" "--mandir=/data/mxe/usr/x86_64-pc-linux-gnu/share/man" "--disable-ldconfig" install: creating uninstall script at /data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/uninstall.sh install: installing component 'cargo' cp: cannot create regular file '/etc/bash_completion.d/cargo': Permission denied chmod: cannot access '/etc/bash_completion.d/cargo': No such file or directory install: error: file creation failed. see logs at '/data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/install.log'
command did not execute successfully: "sh" "/data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/cargo-nightly-x86_64-unknown-linux-gnu/install.sh" "--prefix=/data/mxe/usr/x86_64-pc-linux-gnu" "--sysconfdir=/etc" "--datadir=/data/mxe/usr/x86_64-pc-linux-gnu/share" "--docdir=/data/mxe/usr/x86_64-pc-linux-gnu/share/doc/rust" "--bindir=/data/mxe/usr/x86_64-pc-linux-gnu/bin" "--libdir=/data/mxe/usr/x86_64-pc-linux-gnu/lib" "--mandir=/data/mxe/usr/x86_64-pc-linux-gnu/share/man" "--disable-ldconfig" expected success, got: exit status: 1
Traceback (most recent call last): File "/data/mxe/tmp-rust-x86_64-pc-linux-gnu/rustc-nightly-src/x.py", line 27, in
bootstrap.main() File "/data/mxe/tmp-rust-x86_64-pc-linux-gnu/rustc-nightly-src/src/bootstrap/bootstrap.py", line 1260, in main bootstrap(help_triggered) File "/data/mxe/tmp-rust-x86_64-pc-linux-gnu/rustc-nightly-src/src/bootstrap/bootstrap.py", line 1246, in bootstrap run(args, env=env, verbose=build.verbose, is_bootstrap=True) File "/data/mxe/tmp-rust-x86_64-pc-linux-gnu/rustc-nightly-src/src/bootstrap/bootstrap.py", line 144, in run raise RuntimeError(err) RuntimeError: failed to run: /data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/bootstrap/debug/bootstrap install --keep-stage 1 -j 6 -v make[1]: *** [Makefile:878: build-only-rust_x86_64-pc-linux-gnu] Error 1 make[1]: Leaving directory '/data/mxe'
This log file reerences /data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/install.log, so here it is:
$ umask 022 && mkdir -p "/data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib" $ echo "3" > "/data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/rust-installer-version" install: creating uninstall script at /data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/uninstall.sh $ cp /data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/cargo-nightly-x86_64-unknown-linux-gnu/install.sh /data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/uninstall.sh install: installing component 'cargo' $ echo "cargo" >> "/data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/components" $ umask 022 && mkdir -p "/etc/bash_completion.d" install: copying file /etc/bash_completion.d/cargo $ cp /data/mxe/tmp-rust-x8664-pc-linux-gnu/rustc-nightly-src.build/build/tmp/tarball/cargo/x86_64-unknown-linux-gnu/cargo-nightly-x86_64-unknown-linux-gnu/cargo/etc/bash_completion.d/cargo /etc/bash_completion.d/cargo $ chmod 644 /etc/bash_completion.d/cargo install: error: file creation failed. see logs at '/data/mxe/usr/x86_64-pc-linux-gnu/lib/rustlib/install.log'
FYI, our automated build system is azure devops and I am pointing to a locally virtualized Ubuntu 20.04.3 LTS build client.
It seems Rust installs the system configuration files by default in /etc
.
https://github.com/rust-lang/rust/blob/f04a2f4b8e89eac1119061ea2055d33c97e618b4/config.toml.example#L338
I think I already fixed that with commit https://github.com/libvips/build-win64-mxe/commit/025fed291b6710625933e22fde3a6608242758b4.
diff --git a/build/plugins/llvm-mingw/rust.mk b/build/plugins/llvm-mingw/rust.mk
index 1111111..2222222 100644
--- a/build/plugins/llvm-mingw/rust.mk
+++ b/build/plugins/llvm-mingw/rust.mk
@@ -34,6 +34,7 @@ define $(PKG)_BUILD_$(BUILD)
cd '$(BUILD_DIR)' && $(SOURCE_DIR)/configure \
--prefix='$(PREFIX)/$(BUILD)' \
+ --sysconfdir='etc' \
--release-channel=nightly \
--enable-extended \
--tools=cargo,src \
That worked. It now builds in both WSL and my automated build pipeline.
Thank you very much.
The above patch has landed as commit https://github.com/libvips/build-win64-mxe/commit/f624cf3f3c531296503ffde067037cf88bdb00d8. Thanks for reporting this!
I can confirm that this problem still remains as of the latest commit.
Skip cloning, MXE already exists at /data/mxe
[ignore settings.mk]
== General overrides: /data/overrides.mk
[plugin] /data/plugins/zlib-ng/
[plugin] /data/plugins/llvm-mingw/
[plugin] /data/plugins/proxy-libintl/
[build] cargo-c x86_64-pc-linux-gnu
Failed to build package cargo-c for target x86_64-pc-linux-gnu!
------------------------------------------------------------
error: failed to create directory `/.cargo/registry/cache/index.crates.io-6f17d22bba15001f`
Caused by:
Permission denied (os error 13)
make[1]: *** [Makefile:914: build-only-cargo-c_x86_64-pc-linux-gnu] Error 101
make[1]: Leaving directory '/data/mxe'
real 0m30.505s
user 0m3.154s
sys 0m0.893s
------------------------------------------------------------
[log] /data/mxe/log/cargo-c_x86_64-pc-linux-gnu
make: *** [Makefile:902: /data/mxe/usr/x86_64-pc-linux-gnu/installed/cargo-c] Error 1
Changing the user line in build.sh
mentioned above does fix it though (but I also needed to run a chown root -R
on build/mxe
to fix 'dubious ownership' problems)
@jet082 Should be fixed with commit 4746248b99abc45af4306094576832b2c783ecc2. Thanks for reporting this!
First, I just really want to thank you for this project. It really makes my life so much easier.
I am building web, static, and x86_64 on Ubuntu for Windows (wsl2). If I change the top level build.sh so that I am root in the docker instance, "-u $(id -u):$(id -g) \" changed to "-u 0", then I can build the entire project without issue. If I leave it, then I get a failure in the build/install of rust_x86_64-pc-linux-gnu. This happens on every version of build-win64-mxe including V8.12.1.
rust_x86_64-pc-linux-gnu log file: