On Fri, 8 Aug 2014 16:41:22 +0100, Wookey <woo...@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... Regards, Stephen
signature.asc
Description: PGP signature
