Package Details: mingw-w64-rust 1.75.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-rust.git (read-only, click to copy)
Package Base: mingw-w64-rust
Description: Systems programming language focused on safety, speed and concurrency (mingw-w64)
Upstream URL: https://www.rust-lang.org
Keywords: mingw-w64 rust
Licenses: custom, MIT, Apache
Submitter: pingplug
Maintainer: pingplug
Last Packager: pingplug
Votes: 3
Popularity: 0.000000
First Submitted: 2018-02-13 16:00 (UTC)
Last Updated: 2024-01-01 04:06 (UTC)

Pinned Comments

pingplug commented on 2018-02-14 05:35 (UTC) (edited on 2020-05-20 02:16 (UTC) by pingplug)

  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.

Latest Comments

1 2 3 Next › Last »

syyyr commented on 2023-07-31 12:36 (UTC)

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?

pingplug commented on 2023-01-28 16:38 (UTC)

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

xantares commented on 2023-01-27 19:08 (UTC) (edited on 2023-01-27 19:08 (UTC) by xantares)

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

medzik commented on 2022-05-21 08:28 (UTC)

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

jamincollins commented on 2021-11-24 02:19 (UTC)

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.

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

pingplug commented on 2020-05-20 02:09 (UTC)

@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)

Martchus commented on 2020-05-19 15:57 (UTC)

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.

pingplug commented on 2020-05-19 15:00 (UTC)

@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'

Martchus commented on 2020-05-19 09:59 (UTC)

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.

Martchus commented on 2020-05-18 09:26 (UTC)

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