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

[Dmitrijs Ledkovs]

On 23 November 2010 12:17, Jonathan Nieder <jrnieder at gmail.com> wrote:
> Hi again,
>
> [out of order for convenience]
> Dmitrijs Ledkovs wrote:
>
>> =) can you sponsor our work in the future?
>
> Only if I become DD.  I have not applied yet, so you will probably
> need someone else.
>
> That said, my experience has been that useful, policy-compliant
> patches and packages tend to get integrated.  Maybe one of the
> many wine-using DDs will pick it up once this works well.
>
>> 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.
>

I've tried it. Current debian-gcc packaging is generating
debian/control using m4 and it assembles 3 possible source packages:
gcc, gnat and gcj. Gnat and gcj build-depend on gcc-source package.

debian-gcc is a bit specific to the native libc based toolchains and
cross-toolchains using libc. I didn't manage to find an easy place to
plugin mingw-w64 bootstrap into that packaging.

It would be ideal to share packaging there, but right now it is not
quite easy to do.

Bintuils in the multiarch doesn't build assambler. So a separate
binutils-mingw package will be needed.


>> On 23 November 2010 01:22, Jonathan Nieder <jrnieder at gmail.com> wrote:
>>> Stephen Kitt wrote:
>
>>>> * 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?
>>
>> 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>)
>
>> The assembler and binutils support is there. And you do can dissemble
>> PE exe files and dll with binutils.
>
> This could be useful sometimes, yes.
>
>>>> * 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.
>

Aha. Now I see the point. Well native gcc packaging uses gcc-source
build-dep and we now have continious debian snapshots via web archive
so I think gcc-source of any version can be retrieved.

I guess the package version should reflect which gcc-source was used
during build.

>>> . 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.
>>
>> Which packages do you want to generate from debian/rules? gcc-boostrap
>> + gcc-full? or mingw-w64 and binutils as well? Parse debian/changelog,
>> figure out whether we are bootstrapping the whole toolchain from a
>> single package, or building one or the other component and then build
>> it. This should work with quilt 3.0 source package with tarball
>> componnents --generate-empty-upstream.
>
> What I was suggesting is this:
>
>        debian/rules binary;    # attempts to build gcc-full
>        debian/rules binary BOOTSTRAP=yes;      # builds gcc-bootstrap
>
> which is sort of analagous to
>
>        debian/rules binary TARGET=arm; # builds binutils-arm
>        debian/rules binary;    # builds binutils
>

ok. I was playing around with this. My current plan is to try out:
generating debian/control from debian/control.subpackage*.in files
using sed magic and makefile if statements =) with following
combinations:

1) binutils
2) gcc-bootstrap
3) mingw-w64
3) gcc-bootstrap (skip) - mingw-w64 - gcc-full
4) complete toolchain in one go =)

And generate appropriate debian/control in each case. Our
debian/changelog might go haywire though.....

About source and binary package versions. Source packages will use
sequential release numbers, while at build time binary packages will
get appropriate binary version which matches corresponding versions of
the *-source packages used during build. I don't think this is policy
compliant but doesn't gcc-defaults do exactly that?

>>> I think brief mingw-w64-specific manpages would be ideal.
>>
>> most of the manpages are for gcc and binutils executable. And they are
>> the same as in gcc-doc except that they are prefixed with target
>> tripplet and generate / work against PE object files. These docs are
>> under non-DFSG free license.
>>
>> mingw-w64-specific manpages would be nice, but there aren't written
>> any yet detailing what is special or how to work with mingw-w64
>> toolchain.
>
> This isn't a showstopper, just something nice to have.  (i.e.,
> imho you should feel free to ignore lintian about this)
>
> Thanks for the clarifications.
> Jonathan