Re: RFC: MinGW-w64 toolchain (adoption and new packages)

[Jonathan Nieder <jrnieder@gmail.com>]

Hi again,

[out of order for convenience]
Dmitrijs Ledkovs wrote:

> =) can you sponsor our work in the future?

Only if I become DD.  I have not applied yet, so you will probably
need someone else.

That said, my experience has been that useful, policy-compliant
patches and packages tend to get integrated.  Maybe one of the
many wine-using DDs will pick it up once this works well.

> mingw-w64 do all they work upstream. All patches that were created
> mingw-w64 project are applied directly to binutils and gcc head.

That's great.  One possibility in the long run might be to package
this as part of the usual gcc and binutils packages, then.

> On 23 November 2010 01:22, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Stephen Kitt wrote:

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

Mm, that answers a different question.  What I meant is, is a copy
of binutils-mingw without gcc useful for anything?

Analogy: ordinary binutils without gcc is useful for:

 - compiling firmware and simple binaries written in assembler

 - objdump (see <http://bugs.debian.org/19471>)

> The assembler and binutils support is there. And you do can dissemble
> PE exe files and dll with binutils.

This could be useful sometimes, yes.

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

In the past people have proposed additional packages like gcc-mips
depending at build time on the gcc-source binary package.  This way,
the archive would only need two copies (the .orig.tar.gz and the .deb)
of the gcc source, and variants building separately could reuse that.

The problem with that it required separate work to follow the GPL.
Normally the archive software guarantees that (1) the precise source
package used to build each binary package is available and (2) the
build-time dependencies for packages in "main" are available in some
version from the Debian archive.  So after building gcc-mips,
gcc-source could be updated, and the result would be that gcc-mips
binaries were available for download but the exact corresponding
source would not be.  Avoiding this required some manual configuration
and there were some thoughts about how to make it automatic.

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

What I was suggesting is this:

	debian/rules binary;	# attempts to build gcc-full
	debian/rules binary BOOTSTRAP=yes;	# builds gcc-bootstrap

which is sort of analagous to

	debian/rules binary TARGET=arm;	# builds binutils-arm
	debian/rules binary;	# builds binutils

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

This isn't a showstopper, just something nice to have.  (i.e.,
imho you should feel free to ignore lintian about this)

Thanks for the clarifications.
Jonathan