Somes feeback about "crosscompile-mingw-tedious"

[rboxeur]

First of all thanks for your documentation. It helps me a lot to build my own toolchain on a pure Linux 32Bits machine.

www.davidgis.fr/documentation/Cross-Compil_MPV_on_Linux-32Bits_For_Windows-32Bits_Using_MinGW-w64_5.0.4_GCC-7.2.0/index.html

Restructured document is available at www.davidgis.fr/documentation/Cross-Compil_MPV_on_Linux-32Bits_For_Windows-32Bits_Using_MinGW-w64_5.0.4_GCC-7.2.0/index.rst

I would like to share some notes if you are still maintain this document. This is a pretty nice document. It helps me a lot as a guide for dependancies

Package bzip2: bzip.org website is now down

For the past week, this site is down. You have to download sources using any other URL
(example https://src.fedoraproject.org/lookaside/pkgs/bzip2/bzip2-1.0.6.tar.gz/00b516f4704d4a7cb50a1d97e6e8e15b/bzip2-1.0.6.tar.gz)

Libass package: enable directwrite is recommended for 32 Bits

I built it with and without this flag. I noticed that
without it: mpv on Windows 64 bits can not start
with it: mpv on Windows 64 can start

wine and binfmts

Wine crashed only for one test for Theora while configure is running. But it does not prevent configure to end properly. I used wine-staging 3.15 for the tests

Regards.

[qyot27]

The doc was last pushed to Github 19 days ago (I squash the updates into the original commit and then force-push to Github, which is why the date on the commit still says 2013). During May-June this year it underwent major restructuring to both support out-of-tree builds and multilib (with the old skeleton of the 32-bit crossenv steps moved to a separate file. Normally, big changes or updates occur every six months, after I move onto the current Ubuntu release and rebuild the entire chain. Occasional updates might occur between then, but only as a need arises.

To address the rest:
I was wondering how long it would be before the bzip2.org domain expired. I remembered a Github-based fork that had other improvements made to it (not related to the autoconf support patch), but this was a few years ago and I can no longer find it.

The DirectWrite issue sounds like a conflict with some other lib. I don't use DirectWrite because it has issues dealing with large numbers of installed fonts, and incurs that penalty every time it launches (or when you try seeking, IIRC), as opposed to the one-time (and only subsequently when fonts are added/removed) caching fontconfig does. My personal builds of 32-bit mpv with DirectWrite disabled run fine on 64-bit Windows (as well as on 32-bit Windows, but I've not had the ability to test that since June - the only 32-bit Windows setups I have access to now are WinXP, which mpv and FFmpeg won't run on now anyway). I won't discount that it might be something that has since cropped up in MinGW-w64's 5.x stable git branch since the last time I built the actual compiler toolchain, though.

The reliance on Wine is because some of the dependencies had to be tricked into thinking they were being built on Windows for Windows, rather than cross-compiled. In earlier versions of the guide, this was easy to spot by looking for --build=i686-w64-mingw32 rather than the usual --host=i686-w64-mingw32. Likewise, I had seen people make reference to wine-binfmt causing stuff to break, but I personally have never encountered that.

In the current version, either some of those dependencies have finally been fixed in regard to cross-compilation, or building with a multilib-capable MinGW-w64/GCC papers over it (some of them do still require --build= with multilib, but that's more because I'm using an Apollo Lake platform and the CPU/OS detection gets confused and tries to treat 'silvermont' as part of the triplet, which fails and then proceeds to set the build platform incorrectly). I don't remember whether I hit that particular issue with Theora.

[rboxeur]

Thanks for letting me know and sharing your experience. Your message is particular helpful