Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
(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!