Arch Linux User Repository

1. Rust can not build upon sjlj version of MinGW (i686-w64-mingw32 toolchain in mingw-w64-gcc<10.1.0).
2. building mingw-w64-rust will take about 50GiB, make sure that your $BUILDDIR have enough free space.
3. Rust will check $prefix when packaging, please make an empty $prefix dir (for example /opt/rust) if you don't have one, and don't forget to remove this dir before install this package.
4. THERE IS NO GUARANTEE RUST CAN HOST ITSELF WITH THE SAME VERSION OF RUST! They only test building rust from the last stable version of rust. This package will use the last version of rust for bootstrap, not depend on system rust.
5. to use this, you should add /opt/rust/bin to PATH, and set CARGO_HOME to /opt/rust/cargo.

Hi, Arch Linux recently updated the libgit2 package, which makes mingw-w64-rust not work in some cases (for example when building mingw-w64-librsvg). I think pkgrel should be bumped to trigger a rebuild?

@xantares add --target x86_64-pc-windows-gnu or --target i686-pc-windows-gnu to compile mingw targets

hello,

does anyone know how to compile for mingw targets ?

the provided rustc binary builds for the native linux target:

$ /opt/rust/bin/rustc main.c

$ file main

main: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c044c2aba2aee1a5e0d89c10f5a39d81c996d1ae, for GNU/Linux 4.4.0, not stripped

Why are you downloading older versions of rust, cargo and rust-std? And isn't it better to use rust from extra repo?

Near as I can tell builds of this package are hit by a change in libgit2 that appears to have broken fetching the crates repository.

• https://github.com/rustsec/rustsec/issues/431
• https://stackoverflow.com/questions/69549746/invalid-version-0-on-git-proxy-options-from-libgit2-cause-fix-walk-around
• https://githubmemory.com/repo/killercup/cargo-edit/issues/442

An apparent workaround is to use the vendored libgit2, but I'm not sure how effect that change as part of this build.

@Martchus, now I removed PKGEXT=".pkg.tar.gz" as zstd is fast enough.

Add --keep-stage in package() to reuse binary in build()

use codegen-units=0 to enable multithread codegen(I disabled this at the first time just because my laptop didn't have enough memory)

I haven't tested this, but using xz will take a long time

Ok, so it is just about the time. I guess I'll just add yet another hack to my build system to append PKGEXT=".pkg.tar.zst" to PKGBUILDs so I don't have to care anymore about that.

It's a bug with python3(build stage0 to stage2 twice), switching to python2 may help(python2 didn't support xz, you need to change the source to .tar.gz).

Although I observed the build via htop I can't remember which Python version was primarily used during the build. It might even have used Python 3 most of the time. However, it still needs Python 2 at least in src/bootstrap/sanity.rs:59:13 (whatever that code does - likely nothing with archive extraction; see the error I've pasted in the first comment). So it could be that while already using mostly Python 3 the build still needs Python 2 for some tiny bits.

This check was added in rust half year ago, maybe it has been removed now. I'll try it.

No need to try it. I've ran into this issue and can confirm that the check is still in place.

@Martchus

Or is the default (now zstd) really that bad for this particular package?

I haven't tested this, but using xz will take a long time

By the way, with python2 it builds now so that was the only missing dependency. I've also noticed that the package() phase takes unusually long

It's a bug with python3(build stage0 to stage2 twice), switching to python2 may help(python2 didn't support xz, you need to change the source to .tar.gz).

The requirement to have /opt/rust is a bit annoying

This check was added in rust half year ago, maybe it has been removed now. I'll try it.

I've also noticed that the package does not use all CPU cores.

I'll try 'codegen-units=0'

I would avoid adding configuration variables of makepkg.conf in the PKGBUILD like PKGEXT=".pkg.tar.gz". Or is the default (now zstd) really that bad for this particular package?

By the way, with python2 it builds now so that was the only missing dependency. The requirement to have /opt/rust is a bit annoying when using makechrootpkg but I guess if there was a better solution you would already use it. Yet I'm wondering whether this directory could not simply be adjusted to some path within $srcdir by setting an environment variable. Maybe it is worth pointing out in the pinned comment that this directory must exist but is not populated with files after all (and therefore must not be preserved).

I've also noticed that the package does not use all CPU cores. It seems to spawn "enough processes" but when looking at htop often only one core is used. Not sure whether that can be improved.

I've also noticed that the package() phase takes unusually long and I'm under the impression that the build system actually compiles components again which have already been compiled in the actual build() phase. I'm wondering whether that is right and could be improved.

But thanks for provided the package. This build system must really been annoying to deal with and I appreciate the effort.

Now, since DW2 is enabled by mingw-w64-gcc I'm trying to rebuild. Apparently the dependency python2 is missing:

   Compiling toml v0.5.3
   Compiling bootstrap v0.0.0 (/build/mingw-w64-rust/src/rustc-1.43.1-src/src/bootstrap)
    Finished dev [unoptimized] target(s) in 3m 00s
thread 'main' panicked at '

couldn't find required command: "python2.7"

', src/bootstrap/sanity.rs:59:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failed to run: /build/mingw-w64-rust/src/rustc-1.43.1-src/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 0:03:25
==> ERROR: A failure occurred in build().

https://martchus.no-ip.biz/build-data/rebuild-dw2/mingw-w64-rust/pkg/build.log