Is this a cross-compiled rust or a cross-compiling rust? The description is kind of vague.

This is for cross-compiling rust code from a Fedora host to Windows.

OK, then using the existing rust package:

$ rustc --print target-list | rg windows
aarch64-pc-windows-msvc
i586-pc-windows-msvc
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-uwp-windows-gnu
thumbv7a-pc-windows-msvc
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-uwp-windows-gnu

Are none of these targets usable already?

Can you update your SPEC to latest Rust?

DEBUG util.py:584:  Last metadata expiration check: 0:00:22 ago on Sat Dec  7 22:55:21 2019.
DEBUG util.py:582:  No matching package to install: 'cargo = 1.38.0'
DEBUG util.py:584:  Package make-1:4.2.1-15.fc32.x86_64 is already installed.
DEBUG util.py:582:  No matching package to install: 'rust = 1.38.0'
DEBUG util.py:584:  Package rust-srpm-macros-11-2.fc32.noarch is already installed.
DEBUG util.py:582:  Not all dependencies satisfied
DEBUG util.py:582:  Error: Some packages could not be found.

Thanks for looking at the review - it'll probably be Christmas break until I have time to follow up here.

I still don't understand why the existing Rust targets don't work?

I.e. with librsvg I get

error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-pc-windows-gnu` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static`.


So as far as my rust knowledge goes, you still need the cross-compiled crates, which is where mingw-rust comes into play.

So I think you need only the equivalent of rust-std-static (which has libcore-*.rlib), then? And maybe that can be done with the existing compiler?

I suggest discussing with Josh; maybe it can be produced with the rust build directly.

(In reply to Elliott Sales de Andrade from comment #8)
> maybe it can be produced with the rust build directly.

That should be possible. We're discussing Wasm targets already:

https://src.fedoraproject.org/rpms/rust/pull-request/6

On my part I'm open to whichever approach allows me to finally update mingw-librsvg ;) But I suspect that I'd be hitting the same issue I'm currently hitting with this approach, namely that the package builds fine on all arches [1], but ultimately fails with

BuildError: The following noarch package built differently on different architectures: mingw32-rust-debuginfo-1.41.0-1.fc32.noarch.rpm
rpmdiff output was:
added       /usr/i686-w64-mingw32/lib/rustlib/i686-pc-windows-gnu/lib/std-639345594c286378.dll.debug
removed     /usr/i686-w64-mingw32/lib/rustlib/i686-pc-windows-gnu/lib/std-cf288f9e2d3c8cc5.dll.debug
removed     /usr/i686-w64-mingw32/lib/rustlib/i686-pc-windows-gnu/lib/test-8bf4c31ff797f1ad.dll.debug
added       /usr/i686-w64-mingw32/lib/rustlib/i686-pc-windows-gnu/lib/test-c56b86867130dddf.dll.debug

Basically it looks like the hashes in the filenames are not stable. I've so far not found any pointers out there on how to control these. @Josh, any ideas perhaps?

FWIW, here is the latest attempt:

Spec URL: https://smani.fedorapeople.org/review/mingw-rust.spec
SRPM URL: https://smani.fedorapeople.org/review/mingw-rust-1.41.0-1.fc32.src.rpm


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=41395327

Yeah, we'll have to either make those arch-specific, or figure out and fix the hash difference. I suspect it's just the host triple getting mixed in there. IIRC the last time I tried this, libraries built on one host type were still usable from another host type (both different than the actual target). Most of the upstream host binaries are also cross-compiled from x86_64, which supports that the original host shouldn't really matter.

Will rpmdiff also complain about noarch if we achieve the same filenames, but not completely identical binary contents? I'm not sure the build is 100% reproducible yet.

> I suspect it's just the host triple getting mixed in there.

The hash comes from cargo, which adds two arguments to the build: "rustc ... -C metadata=HASH -C extra-filename=HASH ..."

Cargo's compute_metadata includes rustc.verbose_version (the output of "rustc -Vv"), which does include the host:

(rust-1.41.0-1.fc31.x86_64)
$ rustc -Vv
rustc 1.41.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

(upstream stable)
$ rustc -Vv
rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

Would it be excessively dangerous to do some hacky patchy and filter out the host from rustc -Vv?

I think I'll just send such a PR to cargo and see what they say... :)

Cool, thanks!

Posted here: https://github.com/rust-lang/cargo/pull/7873

Ok me had an idea: I'll workaround rpmdiff comparing the packages across build arches by adding %{arch} to the subpackage name, and just have the subpackage provide the proper name, say:

%package -n mingw32-%{pkgname}-%{_arch}
Summary:       MinGW Windows Rust Toolchain
Provides:      mingw32-%{pkgname} = %{version}-%{release}

And this actually builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=55537452 :)

---

Spec URL: https://smani.fedorapeople.org/review/mingw-rust.spec
SRPM URL: https://smani.fedorapeople.org/review/mingw-rust-1.47.0-1.fc34.src.rpm
Description: MinGW Windows Rust Toolchain
Fedora Account System Username: smani

 - Bump to latest available rust

 I tried building with 1.49.0 but it failed after a lonq time:

Build completed successfully in 0:04:50
+ find /builddir/build/BUILDROOT/mingw-rust-1.49.0-1.fc34.x86_64 -type f -name '*.so' -exec chmod +x '{}' ';'
+ cd /builddir/build/BUILDROOT/mingw-rust-1.49.0-1.fc34.x86_64/usr/i686-w64-mingw32/lib/rustlib/x86_64-unknown-linux-gnu/lib
/var/tmp/rpm-tmp.f2suP4: line 48: cd: /builddir/build/BUILDROOT/mingw-rust-1.49.0-1.fc34.x86_64/usr/i686-w64-mingw32/lib/rustlib/x86_64-unknown-linux-gnu/lib: No such file or directory

The rust triple I get in /builddir/build/BUILDROOT/mingw-rust-1.49.0-1.fc34.x86_64/usr/i686-w64-mingw32/lib/rustlib/ is i686-pc-windows-gnu not x86_64-unknown-linux-gnu

I've opened a PR to add mingw subpackages to the main rust package -- please try it out!
https://src.fedoraproject.org/rpms/rust/pull-request/14

Oh awesome, yes Ì'll try it out, thanks!

mingw subpackages available in rust-1.57.0-2.fc36+ (thanks Josh!)