[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch capabilities for mingw crossbuilds too?

On Fri, 8 Aug 2014 16:41:22 +0100, Wookey <wookey@wookware.org> wrote:
> +++ Joerg Desch [2014-08-08 05:38 +0000]:
> > Today I've read about Debians Multiarch capabilities for the first time. 
> > Is it possible to use this technique to build deb packages of libraries 
> > for the mingw crosscompile toolchain too?
> In principle, yes. In practice right now, no. Stephen Kitt has looked
> into this and gave a comprehensive talk at this year's mini-debconf
> (But I can't find a URL as I'm not sure that Sylvestre has actually
> uploaded them anywhere). I think this pdf is the slides though:
> http://www.sk2.org/talks/crossporting-to-windows.pdf

That's it; the video isn't available (yet?).

> It has the potential to be exceedingly slick and remove a whole load
> of packaging cruft we currently have to make windows/mingw-ready versions of
> libraries.
> There is some discussion on this therad:
> https://lists.debian.org/debian-devel/2011/04/msg01243.html
> > I have to build Windows executables and therefore need some libraries. 
> > For now, I build and install them locally. It would be fine to have a
> > way just to apt-get install them.
> > 
> > Any chance?
> Yes, but it needs some work. I'm sure Stephen would love some help :-) 
> I don't know if he's made any progress since feb.

I've been mostly working on the change requested by Guillem in 
https://bugs.debian.org/606825 so that we can get "Windows" added as an
architecture in dpkg, which is the first step towards a multi-arched
MinGW-w64 toolchain. I need to write stuff up to follow up on the bug, the
short version is that it's very complicated and I now understand very well
why upstream went for a imperfect triplet.

As Wookey says, I'd love some help, once there are things to help with. Keep
an eye on #606825, and once the architecture exists in dpkg we'll be able to
start fixing up packages (debian-ports style) and anyone interested will be
able to chip in!

> The trickiest part is that, having demonstrated that this works, we
> would have to change the definition of 'architecture independent' a
> little to include 'posix/non-posix' which mostly means moving a lot of
> libc stuff from arch-independent locations to arch-dependent
> locations, and that might be a hard sell in Debian. It _should_ only
> affect libc packaging, but work needs to be done to demonstrate
> that. Everything else is straightforward, and indeed a simplification of
> the current state for any package that produces win32/64 libs.

That's a very accurate summary, thanks! And the next big hurdle after getting
dpkg updated...



Attachment: signature.asc
Description: PGP signature

Reply to: