[pkg-wine-party] RFC: MinGW-w64 toolchain (adoption and new packages)

[Jonathan Nieder]

(+cc: the almost-defunct debian-toolchain@ list, for posterity's sake)

Hi Stephen,

Stephen Kitt wrote:

> I'm working on packaging a new version of the MinGW-w64 toolchain, which
> allows 32- and 64-bit Windows software to be compiled as a cross-compiler
> target using gcc.

Sounds neat.  Have there been any efforts on integrating this work into
upstream GCC?

> * binutils-mingw-w64, a simple binutils-source-based package providing
>   binutils targetting MinGW-w64's triplets;

Any examples for how this can be used directly?  e.g., can simple
Windows toys in assembler be compiled this way, and can it help with
analyzing binaries from such systems?

> * gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc
>   targetting MinGW-w64's triplets;

I don't remember how far the dak work has proceeded in supporting this. :(

> * mingw-w64, the MinGW-w64 development headers and libraries.

That means libc, I guess.

> MinGW-w64 now has its own official triplets, differing from MinGW's which are
> what had been used so far in Debian with the gcc-mingw32 and co. packages.
> This is why new packages are needed

Thanks for explaining.

> Building the packages is slightly involved:
> 1. Build binutils-mingw-w64 and install it.

So the first step could be to get this package alone in Debian.

> 2. Extract gcc-mingw-w64, and change the debian/control and
>    debian/rules.variant links so they point to debian/control.bootstrap and
>    debian/rules.bootstrap respectively.
> 3. Build gcc-mingw-w64 and install the resulting gcc-mingw-w64-bootstrap
>    package.
> 4. Build mingw-w64 and install the resulting mingw-w64-dev package.
> 5. Return to the gcc-mingw-w64 folder, and clean the build
> 	fakeroot debian/rules clean
> 6. Change the debian/control and debian/rules.variant links so they point to
>    debian/control.full and debian/rules.full.
> 7. Build gcc-mingw-w64.
> 
> Note that since mingw-w64-dev is "Architecture: all", this should only be
> required to prepare the first upload.

Yagh.  I guess Debian infrastructure does not take care of multi-package
bootstrapping scenarios so well.  The general scheme seems sane; I
just have three suggestions:

. It would be simpler to have only one debian/rules file, with a
  makefile variable to control which packages get built.  See the
  binutils package for an example.

. debian/rules is allowed to generate debian/control, so one would only
  need one starting debian/control for this.  See the binutils package
  for an example.

. Maybe an example script in mingw-w64-dev's debian/README.source would
  be helpful for people trying to figure out how the bootstrap worked.

It is nice that the dependency loop can be broken by uploading an
Arch: all package.

>                                   Also note that while this bootstrapping
> sequence follows the existing Debian packaging structure, with separate
> binutils, gcc and mingw packages, Dmitrijs Ledkovs (who is assisting me
> with this packaging effort) has an alternative scheme with a single
> self-bootstrapping package at https://launchpad.net/~mingw-w64

Yes, I tend to prefer the multiple-package method, too.

> binutils has manpage errors and spelling errors in its binaries, none of
> which I thought really warranted fixing (especially since they're all in
> binutils-source anyway).

Please feel free to file a bug, especially if you have time to write a
patch.

>                         gcc emits the following:
> * debian-control-file-is-a-symlink

See above.

> * copyright-refers-to-symlink-license: this is part of debian/copyright which
>   is reproduced from gcc-4.5-source's, and justified IMO; the
>   version-specific licence symlink follows it immediately;

Perhaps this is worth a bug on the lintian package?

> * binary-without-manpage: on the todo list, although it doesn't seem
>   particularly urgent to me; should MinGW-w64-specific manpages be provided,
>   or would it do to just symlink the (old) gcc manpages?

I think brief mingw-w64-specific manpages would be ideal.

> mingw-w64 has a ton of warnings, all instances of non-standard-dir-in-usr or
> file-in-unusual-dir because it ships its headers and libraries
> in /usr/$target/{include,lib}.

Sounds like a lintian bug.

> gcc-mingw-w64 will eventually be split up, to provide smaller packages
> providing the various compilers, headers and libraries in a similar fashion
> to the mainline gcc package.

By this, you mean split into multiple binary packages, right?

> * once the packages have been tested in actual use, we'll determine with Ron
>   Lee whether it is useful to keep MinGW32 in Debian along with MinGW-w64.
>
> Thanks in advance for any comments!

Thanks for your hard work.  Sounds very good.

Regards,
Jonathan