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

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sun, 24 Apr 2011 22:46:40 +0100, Wookey <wookey@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

% dpkg-architecture -amingw64-i386 
dpkg-architecture: warning: Specified GNU system type i486-w64-mingw32 does not match gcc system type i486-linux-gnu.

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,


Attachment: signature.asc
Description: PGP signature

Reply to: