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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101123105501.gg9...@sk2.org
