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

Stephen Kitt steve at sk2.org
Sat Dec 11 16:40:05 UTC 2010

On Sat, 11 Dec 2010 17:28:10 +1030, Ron <ron at debian.org> wrote:
> On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote:
> > On 23.11.2010 12:49, Dmitrijs Ledkovs wrote:
> > >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.
> > 
> > You might want to have a look at Marcin's cross-build packages,
> > using the gcc-, binutils- and eglibc- source packages.
> I wasn't aware of Marcin's work, but I also agree this is probably
> the best avenue to explore if these are all building from identical
> source.  I believe Robert's original attempt even did exactly this,
> and I tried to point Stephen in this direction too when he first
> contacted me, but I think that point got lost, and I got too busy
> to point again in more detail immediately.

I'm not sure whether it got lost or not, my packages (with Dmitrijs'
contributions) currently build-depend on binutils-source and gcc-4.5-source
and avoid duplicating anything from the original binutils and gcc packages; in
fact I went to some effort (see my bug reports against gcc-4.5-source, now
resolved) to make sure the resulting packages would not only use the tarballs
provided in the -source packages but also apply any relevant patches.

> AIUI, the main problem with this is that the distro archive tools
> currently don't have good support for ensuring these 'binary' -source
> packages will remain available and linked to the derivative binary
> debs that might be built from them and uploaded to the distro.
> I believe ftp-master indicated to Robert that this could be fixed,
> but he went back to the quick and dirty duplication instead.  If
> there are people with time to spend on this, talking to the archive
> maintenance people about what needs to be done for that, and when
> and how it might happen, is probably a productive step at this point.

Indeed; I'm not sure what Matthias means by

On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose <doko at debian.org> wrote:
> this is already guaranteed by the gcj and gnat builds by only relying on
> the tarball in the gcc-4.x-source package.

I imagine this could mean that the gcj and gnats builds don't use the patches
in the gcc-4.x-source package, and only use the tarball which won't change
from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)... That
seems a shame to me since the patches are useful, and it still leaves the
problem of having a package build using gcc-4.5-source 4.5-1 for example, and
then gcc-4.5-source being replaced with version 4.5.1-1 with a new tarball.

Matthias, is that what you meant?

I'll take it up with ftpmaster as you suggest, Ron!

The other solution based on Marcin's work, which is also readily supported by
the existing -source packages, requires that the target architecture be
understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile
goal, notably since it solves the problem of how to provide build packages
for the various libraries people find useful, but it's a much longer-term
goal as far as I can see...



More information about the pkg-wine-party mailing list