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

[Dmitrijs Ledkovs]

On 23 November 2010 01:22, Jonathan Nieder <jrnieder at gmail.com> wrote:
> (+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?
>

mingw-w64 do all they work upstream. All patches that were created
mingw-w64 project are applied directly to binutils and gcc head. There
is a pending patch to pthreads-win32.

mingw-w64 is runtime, tools to generate headers and microsoft
compatible runtime loadable library. There are also headers to support
compilation against windows vista, windows 7 and directx but I haven't
personally tested that.

>> * 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?
>

The following projects (taken from mingw-w64 website) confirmed using
ming-w64 based toolchain to provide windows releases:

Hexen II: Hammer of Thyrion
FFmpeg
OpenSC
Wine
MAME (Yes, the arcade emulator!)
ReactOS
VideoLAN VLC
pthreads
OpenSSL
wxWidgets
Code::Blocks
FLTK
SBC Archiver
OpenLisp
GTK+
GIMP
mpg123
Factor
JPen
iAuxSoft
ReMooD
Emerge Desktop
libsndfile
wxPerl PPMs
zlib
The R Project for Statistical Computing
Perl (5.12.0 and later)
Strawberry Perl (contains bundled mingw-w64 gcc toolchain)
QuakeSpasm
GNU SASL
GnuTLS
OpenFOAM
MS MPI
Libxml2

The assembler and binutils support is there. And you do can dissemble
PE exe files and dll with binutils. I'm not sure whether binutils can
by it self analyse .NET intermediate language code or whether mono
install packages are required as well for that.

>> * 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. :(
>

How is dak involved? This will be just a regular binary deb package.

>> * mingw-w64, the MinGW-w64 development headers and libraries.
>
> That means libc, I guess.
>

yes, kind of. Microsoft compatible runtime (dll's) + headers. usually
abriviated as crt.

>> 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.
>

Which packages do you want to generate from debian/rules? gcc-boostrap
+ gcc-full? or mingw-w64 and binutils as well? Parse debian/changelog,
figure out whether we are bootstrapping the whole toolchain from a
single package, or building one or the other component and then build
it. This should work with quilt 3.0 source package with tarball
componnents --generate-empty-upstream.

> . 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.
>

Fair enough =)

It's just binutils and gcc packages do not have source tarballs, they
build-dep on gcc-source and binutils-source packages.

>> 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.
>

most of the manpages are for gcc and binutils executable. And they are
the same as in gcc-doc except that they are prefixed with target
tripplet and generate / work against PE object files. These docs are
under non-DFSG free license.

mingw-w64-specific manpages would be nice, but there aren't written
any yet detailing what is special or how to work with mingw-w64
toolchain.

>> 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.
>

Lintian, doesn't seam to support multiarch/cross-toolchain package layouts.

>> 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?
>

yes. we want to atleast split: c/c++, fortran, java+ada+objc. Or even
split the last three into separate binary packages as well.

>> * 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.
>

=) can you sponsor our work in the future?

> Regards,
> Jonathan
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mingw-w64
> Post to     : mingw-w64 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~mingw-w64
> More help   : https://help.launchpad.net/ListHelp
>