[pkg-wine-party] [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
steve at sk2.org
Tue Nov 23 10:55:02 UTC 2010
(I'll reply separately to the remaining points from your earlier
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
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
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
In addition, how would the use of a Makefile variable work on the
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!
More information about the pkg-wine-party