Bug 1762856 - Review Request: mingw-rust - MinGW Windows Rust Toolchain
Summary: Review Request: mingw-rust - MinGW Windows Rust Toolchain
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-17 16:42 UTC by Sandro Mani
Modified: 2021-01-29 18:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---


Attachments (Terms of Use)

Description Sandro Mani 2019-10-17 16:42:58 UTC
Spec URL: https://smani.fedorapeople.org/review/mingw-rust.spec
SRPM URL: https://smani.fedorapeople.org/review/mingw-rust-1.38.0-1.fc32.src.rpm
Description: MinGW Windows Rust Toolchain
Fedora Account System Username: smani

Comment 1 Elliott Sales de Andrade 2019-10-26 08:45:19 UTC
Is this a cross-compiled rust or a cross-compiling rust? The description is kind of vague.

Comment 2 Sandro Mani 2019-10-26 19:27:15 UTC
This is for cross-compiling rust code from a Fedora host to Windows.

Comment 3 Elliott Sales de Andrade 2019-10-28 19:50:29 UTC
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?

Comment 4 Robert-André Mauchin 🐧 2019-12-07 21:58:33 UTC
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.

Comment 5 Sandro Mani 2019-12-09 13:36:45 UTC
Thanks for looking at the review - it'll probably be Christmas break until I have time to follow up here.

Comment 6 Elliott Sales de Andrade 2019-12-10 04:35:21 UTC
I still don't understand why the existing Rust targets don't work?

Comment 7 Sandro Mani 2019-12-10 09:09:26 UTC
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.

Comment 8 Elliott Sales de Andrade 2019-12-14 03:19:36 UTC
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.

Comment 9 Josh Stone 2019-12-16 17:48:05 UTC
(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

Comment 10 Sandro Mani 2020-02-05 22:26:55 UTC
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

Comment 11 Josh Stone 2020-02-05 23:13:30 UTC
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.

Comment 12 Josh Stone 2020-02-05 23:58:48 UTC
> 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

Comment 13 Sandro Mani 2020-02-06 00:02:15 UTC
Would it be excessively dangerous to do some hacky patchy and filter out the host from rustc -Vv?

Comment 14 Josh Stone 2020-02-06 00:04:35 UTC
I think I'll just send such a PR to cargo and see what they say... :)

Comment 15 Sandro Mani 2020-02-06 00:16:42 UTC
Cool, thanks!

Comment 16 Josh Stone 2020-02-06 22:57:41 UTC
Posted here: https://github.com/rust-lang/cargo/pull/7873

Comment 17 Sandro Mani 2020-11-13 20:29:40 UTC
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

Comment 18 Robert-André Mauchin 🐧 2021-01-29 18:08:40 UTC
 - 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

Comment 19 Robert-André Mauchin 🐧 2021-01-29 18:11:36 UTC
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


Note You need to log in before you can comment on or make changes to this bug.