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

[Stephen Kitt]

Hi Jonathan,

(I'll reply separately to the remaining points from your earlier
email.)

On Tue, Nov 23, 2010 at 04:17:32AM -0600, Jonathan Nieder wrote:
> > 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.

Yes, that would definitely be a possibility, in the same vein as the
existing -hppa64 and -spu packages. It would add an odd
build-dependency on gcc though (mingw-w64-dev), which might not sit
too well with some people!

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

A number of binutils tools are useful without gcc when working with
Windows executables: objdump, windmc, windres, dlltool at least. ld is
also useful when working with assembly code, gas less so since most
such code targets NASM or MASM in the Windows world.

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

I see... gcc-avr is in the archive and depends on gcc-4.3-source, so
there is a precedent (which is why I pursued this idea). Do you reckon
this would be a problem when it comes to getting gcc-mingw-w64 into
the archive?

There is another advantage to build-depending on gcc-4.5-source: in
addition to reducing the storage requirements, we also automatically
benefit from the various patches in the Debian package (and any future
updates).

What manual configuration is involved?

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

I know it's possible to do this, but in gcc-mingw-w64's case the build
dependencies change, so generating debian/control from debian/rules
doesn't work. Using a symlink to fix this seemed OK to me, and once
control is a symlink, rules might as well use one too; I didn't think
it would necessarily be a good idea to have two different setups to
think about when bootstrapping the package (symlink control and set a
Makefile variable).

In addition, how would the use of a Makefile variable work on the
buildds?

I'm adding a shell script to automate the operations involved in
bootstrapping the gcc package though, it's in the git repository.

Thanks for taking the time to look into all this!

Regards,

Stephen