On Sun, 24 Apr 2011 22:46:40 +0100, Wookey <woo...@wookware.org> wrote: > +++ Stephen Kitt [2011-04-24 19:14 +0200]: > > > So I would be opposed to making such a change in policy for the time > > > being; I think cross-compilers should stick with the traditional > > > cross-compiler directories and stay away from the multiarch directories > > > until we have more practical experience with multiarch under our belts > > > and can make some educated decisions about how we want this to all fit > > > together. > > > > OK. > > I expect the multiarch paths to replace the 'traditional > cross-compiling' paths in due course for all target architectures, > including ones that aren't Debian-suported (i.e currently > mingw-whatever-you-call-it, avr32, msp430), for both native use and > cross-compiling. Steve will have to explain to me why we might want to > use different paths for non-self-hosting arches. It seems to me that > having one canonical place to look for arch-dependent files is good > whether you want them for running or for (cross-)building. > > But we do need to proceed carefully in order to get this right, and > the cross-only arches are a little way down our list of issues :-) I'd > be interested to hear how you currently do things in mingw world (and > more importantly what things you want to be able to do) so that we can > take your needs into account.
I personnally don't speak for upstream, and most of the documentation available upstream discusses either Windows builds or sysroot-based builds in /usr/local. There has been a fair amount of discussion in the past though, including a proposed patch for dpkg (http://bugs.debian.org/606825) and a specification document on the Debian wiki (http://wiki.debian.org/Mingw-W64 which also has links to other distributions' documentation). I don't particularly like the sysroot approach, and I believe multiarch would provide the same functionality, i.e. being able to host at least the headers and libraries (and link-time DLLs) for cross-compiled libraries. I see two immediate requirements for MinGW-w64 in Debian: * being able to build wine-gecko; * replacing mingw32 and gcc-mingw32. Looking further, being able to host -dev packages to provide a nice cross-building environment would be desirable. Being able to host cross-compiled runtime binaries and DLLs doesn't seem quite so useful to me, although people using Debian to build installation packages for Windows would probably disagree. > I do think that getting the 'win32' arch name and triplet defined in > dpkg-architecture is stage 1 for you. I thought we'd already done that > years ago, when this last came up, but obviously not. > dpkg-architecture already supports 269 options including such > not-very-useful combinations as uclibc-linux-s390 and solaris-alpha, > so it really ought to know about the win32 and win64 ABIs. It's > generally a very simple patch to a few tables in dpkg to add a new arch. > > Having the mappings between Debian arch name, gnu triplet and multiarch > path all in one place is vital to making all this stuff work properly. It is indeed, see above for the existing bug report. I take it people were perhaps awaiting Dmitrijs' test results before pursuing things; I've built a patched dpkg and so far the results seem OK, although perhaps not to Adam's liking since the multiarch directories still end up being MinGW-w64 specific: % dpkg-architecture -amingw64-amd64 dpkg-architecture: warning: Specified GNU system type x86_64-w64-mingw32 does not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=mingw64-amd64 DEB_HOST_ARCH_OS=windows DEB_HOST_ARCH_CPU=amd64 DEB_HOST_ARCH_BITS=64 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=x86_64 DEB_HOST_GNU_SYSTEM=w64-mingw32 DEB_HOST_GNU_TYPE=x86_64-w64-mingw32 DEB_HOST_MULTIARCH=x86_64-w64-mingw32 % dpkg-architecture -amingw64-i386 dpkg-architecture: warning: Specified GNU system type i486-w64-mingw32 does not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=mingw64-i386 DEB_HOST_ARCH_OS=windows DEB_HOST_ARCH_CPU=i386 DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=w64-mingw32 DEB_HOST_GNU_TYPE=i486-w64-mingw32 DEB_HOST_MULTIARCH=i386-w64-mingw32 Other distributions and upstream always use i686 for 32-bit MinGW-w64, which is why I used that too in my current packages. I believe it would still be possible to have a multiarch using Debian's CPU definitions as above, but build binutils and gcc with the i686-based triplet so that the commands would be the same as elsewhere - wouldn't it? > Please make sure you get the names right - changing them later will be > very painful. A multiarch name signifies an ABI, as explained in more > detail here: http://wiki.debian.org/Multiarch/Tuples > (note that that proposal is no longer current, but does explain what a > multiarch ABI name is and isn't). Yes, and I think the above is correct, although I'd like to build test packages using the above dpkg-architecture (and multiarch-style paths, even though uploading such packages would have to wait) and see how things go with the various mingw32-based packages currently in Debian before the change to dpkg becomes permanent. > > Would it make any sense then to add an exception for traditional > > cross-compiler directories, or should cross-compiling library packages > > simply continue using lintian overrides? > > So you ship packages pre-built to install to the traditional > cross-compiler dirs (as opposed to making them with dpkg-cross as we > do on arches where native packages are shipped). Makes sense. I think > that packages installing to those paths should continue using lintian > overrides as they are very much 'non-standard'. OK! I ship pre-built packages in this way because they're also used as build-dependencies for other packages in Debian, which I gather would be difficult using dpkg-cross. > > One last question: without considering multiarch, what is the situation > > regarding headers? Is the proposal in http://bugs.debian.org/542865 still > > the intended approach, or is there another solution? > > Headers are deliberately excluded from the scope of > https://wiki.ubuntu.com/MultiarchSpec in order to shink the problem > space down into something that it would only take 6 years to implmenet > :-) > > However the extra bits for cross-compiling using multiarch paths are > detailed here: https://wiki.ubuntu.com/MultiarchCross and we are > already implementing that stuff. > > Arch-dependent headers will go into /usr/include/<multiarchpath> and > arch independent headers will stay in /usr/include. We can also just > put all headers in /usr/include/<multiarchpath>, and have duplication > (as we already do for the traditional paths) if the above is > problematic, however it seems to be working fine for the few packages > changed so far, so spliting the arch-dependent ones out seems like the > way to go. That's what I understood based on Steve's comment and from reading those wiki pages too. Thanks for your input, Stephen
signature.asc
Description: PGP signature
