Proposed SIG: Windows MinGW cross-compiler SIG

[Daniel P. Berrange]

On Tue, Jul 08, 2008 at 03:46:40PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:
> > > I've got a self-building, mostly working set of Fedora packages for
> > > the MinGW cross-compiler (no optional libraries yet).  You can get the
> > > spec files and instructions by doing:
> > > 
> > >   hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel
> > 
> > What primarily concerns me is that plan around keeping this in sync
> > with patches/updates to the main gcc, binutils, libpng, libgcrypt,
> > gnutls, etc RPMS already in Fedora.
> > 
> > The idea of maintaining 2 near identical specs & builds for all these
> > packages isn't that nice, particularly since many of these are security
> > sensitive packages
> 
> So there's a bit of confusion going around, partly my own.
> 
> Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408)
> starts with a forked version of binutils maintained by mingw. They
> have their own release schedule for this so I'm not sure how viable it
> is to have a single binutils SPEC file generating both the normal
> binutils and a 'binutils-mingw' subpackage.  (Ignoring for now whether
> or not the Fedora binutils maintainer is even interested in this)

It is rather a shame Mingw can't submit their changes upstream, or at
least provide patches against upstream rather than re-spinning the
entire tar.gz.  But since that's the way they've  done it I guess we
have no choice but to work with it as a forked package in the short
term.

> Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts
> from plain gcc 4.3.1 source, so combining these into Fedora's gcc
> package might be more hopeful.  However there are some nasty
> dependencies (mingw-runtime and mingw-w32api, neither of which can be
> built ab initio because of circular dependencies) and I suspect that
> any time there is any sort of mingw related trouble with this package,
> the gcc-mingw subpackage will be the first to be dropped.  I don't
> want this.

I must say the complexity of the existing GCC RPM in Fedora is pretty
scary, and more to the point seems to want pretty strict versions of
binutils which given the fork'ing of binutils by MinGW is a pain point.

> As for the remainder we get into asking question like -- should we
> generate the mingw-gnutls library (as an example) from the main gnutls
> SPEC file?  There are going to be dozens of such libraries and we'll
> have to coordinate with a large number of existing Fedora contributors
> to make this happen.

This is where it gets non-scalable if we have a forked SPEC for every
library we want to build for mingw. We need to make it easy for the
maintainence of all the libs to be devolved to the existing maintainers
of the libraries, preferably with little-to-no extra work for these
maintainers. We shouldn't get into the world of maintaining two
independant copies of things like GNUTLS, libpng, libvirt, etc.

If we can get away with only having mingw custom packages for gcc,binutils,
and the runtime, and then sub-RPM for all the other bits I'd be reasonably
satisfied.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|