(+cc: the almost-defunct debian-toolchain@ list, for posterity's sake) Hi Stephen,
Stephen Kitt wrote: > I'm working on packaging a new version of the MinGW-w64 toolchain, which > allows 32- and 64-bit Windows software to be compiled as a cross-compiler > target using gcc. Sounds neat. Have there been any efforts on integrating this work into upstream GCC? > * 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? > * 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. :( > * mingw-w64, the MinGW-w64 development headers and libraries. That means libc, I guess. > MinGW-w64 now has its own official triplets, differing from MinGW's which are > what had been used so far in Debian with the gcc-mingw32 and co. packages. > This is why new packages are needed Thanks for explaining. > Building the packages is slightly involved: > 1. Build binutils-mingw-w64 and install it. So the first step could be to get this package alone in Debian. > 2. Extract gcc-mingw-w64, and change the debian/control and > debian/rules.variant links so they point to debian/control.bootstrap and > debian/rules.bootstrap respectively. > 3. Build gcc-mingw-w64 and install the resulting gcc-mingw-w64-bootstrap > package. > 4. Build mingw-w64 and install the resulting mingw-w64-dev package. > 5. Return to the gcc-mingw-w64 folder, and clean the build > fakeroot debian/rules clean > 6. Change the debian/control and debian/rules.variant links so they point to > debian/control.full and debian/rules.full. > 7. Build gcc-mingw-w64. > > Note that since mingw-w64-dev is "Architecture: all", this should only be > required to prepare the first upload. Yagh. I guess Debian infrastructure does not take care of multi-package bootstrapping scenarios so well. The general scheme seems sane; I just have three suggestions: . 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. . Maybe an example script in mingw-w64-dev's debian/README.source would be helpful for people trying to figure out how the bootstrap worked. It is nice that the dependency loop can be broken by uploading an Arch: all package. > Also note that while this bootstrapping > sequence follows the existing Debian packaging structure, with separate > binutils, gcc and mingw packages, Dmitrijs Ledkovs (who is assisting me > with this packaging effort) has an alternative scheme with a single > self-bootstrapping package at https://launchpad.net/~mingw-w64 Yes, I tend to prefer the multiple-package method, too. > binutils has manpage errors and spelling errors in its binaries, none of > which I thought really warranted fixing (especially since they're all in > binutils-source anyway). Please feel free to file a bug, especially if you have time to write a patch. > gcc emits the following: > * debian-control-file-is-a-symlink See above. > * copyright-refers-to-symlink-license: this is part of debian/copyright which > is reproduced from gcc-4.5-source's, and justified IMO; the > version-specific licence symlink follows it immediately; Perhaps this is worth a bug on the lintian package? > * binary-without-manpage: on the todo list, although it doesn't seem > particularly urgent to me; should MinGW-w64-specific manpages be provided, > or would it do to just symlink the (old) gcc manpages? I think brief mingw-w64-specific manpages would be ideal. > mingw-w64 has a ton of warnings, all instances of non-standard-dir-in-usr or > file-in-unusual-dir because it ships its headers and libraries > in /usr/$target/{include,lib}. Sounds like a lintian bug. > gcc-mingw-w64 will eventually be split up, to provide smaller packages > providing the various compilers, headers and libraries in a similar fashion > to the mainline gcc package. By this, you mean split into multiple binary packages, right? > * once the packages have been tested in actual use, we'll determine with Ron > Lee whether it is useful to keep MinGW32 in Debian along with MinGW-w64. > > Thanks in advance for any comments! Thanks for your hard work. Sounds very good. Regards, Jonathan -- 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/20101122232241.ga2...@burratino
