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

Stephen Kitt steve at sk2.org
Mon Nov 22 06:25:13 UTC 2010

Dear mentors,

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. This all started with the requirement for a new version of
gcc and MinGW-w64 to build wine-gecko, the browser engine used by Wine, but
MinGW-w64 is more than just a build dependency for Wine.

The way I've packaged the toolchain so far involves three packages:
* binutils-mingw-w64, a simple binutils-source-based package providing
  binutils targetting MinGW-w64's triplets;
* gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc
  targetting MinGW-w64's triplets;
* mingw-w64, the MinGW-w64 development headers and libraries.

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; upstream would also like it to be clear
these are MinGW-w64 packages and not MinGW (formerly MinGW32) packages.

Everything is available at http://www.sk2.org/mingw-w64, along with a
wine-gecko package which allows the toolchain to be tested.
binutils-mingw-w64 and mingw-w64 are also on mentors.debian.net, but
gcc-mingw-w64 and wine-gecko won't upload for some reason. The DSCs are
* http://www.sk2.org/mingw-w64/binutils-mingw-w64_2.20.1-1.dsc
* http://www.sk2.org/mingw-w64/gcc-mingw-w64_4.5.1-1.dsc
* http://www.sk2.org/mingw-w64/mingw-w64_1.0+20101003-1.dsc
* http://www.sk2.org/mingw-w64/wine-gecko-1.0.0_1.0.0+dfsg-1.dsc

The first three are also hosted on Alioth:
* http://git.debian.org/?p=collab-maint/binutils-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/gcc-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/mingw-w64.git;a=summary

Building the packages is slightly involved:
1. Build binutils-mingw-w64 and install it.
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
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. Once the packages are in Debian, future
versions will be easier to build! 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

As far as Lintian is concerned, all the packages have a number of warnings.
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). gcc emits the following:
* debian-control-file-is-a-symlink: this is done on purpose, to make
  bootstrapping easier; once the first upload is in Debian the symlink can be
  removed (while preserving the bootstrap files for documentation purposes
  and should they ever become necessary in the future again);
* 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;
* 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?
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}. I'm not sure what (if anything - the existing
packages in Debian do this too) should be done about this.

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. For now it's a single package to make
bootstrapping easier.

The aim of this email is primarily to get feedback on the general approach
and any specific issues with the packages themselves. Obviously if the
packages are deemed upload-worthy and a sponsor volunteers I won't complain

As far as the variety of MinGW packages in Debian is concerned, the plan is
as follows:
* this set of packages should allow Robert Millan's set of (orphaned)
  packages to be dropped entirely (this is gcc-mingw32 and the packages
  formerly built by mingw-w64);
* 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!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wine-party/attachments/20101122/ca874621/attachment-0001.pgp>

More information about the pkg-wine-party mailing list