Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
+++ 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 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.
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).
> 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'.
> 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.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: