On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote:
> Stephen Kitt <steve@sk2.org> writes:
> > Now that multiarch is here, I've been wondering whether and how it applies to
> > cross-compiler libraries for non-Debian architectures.
[...]
> > It seems to me though that it would be nice to follow the multiarch directory
> > structure for cross-compilers to non-Debian architectures
[...]
> > Thus for example mingw-w64-dev would install headers
> > in /usr/include/{i686,x86_64}-w64-mingw32 and libraries
> > in /usr/lib/{i686,x86_64}-w64-mingw32 instead of the
> > current /usr/{i686,x86_64}-w64-mingw32/{include,lib} (which isn't
> > FHS-compliant)
[...]
> > Would it be acceptable to introduce an exception to policy allowing this?
> > Something along the lines of
> >
> > An exception is granted for `Architecture: all' packages containing
> > libraries targeting platforms for which there is no Debian
> > architecture. Such packages may use their traditional triplet as
> > recognised by binutils and gcc.
> >
> > (The phrasing is certainly not perfect; this ends up being an exception to an
> > exception...)
>
> I would rather add a new architecture to dpkg for this. This does not
> mean that debian has to create a new port or that the packages have to
> stop being arch:all. But dpkg should know about it and be the one and
> only place packages query for the right multiarch triplet. Then you
> would use
> /usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH)
> when building your package. Problem solved.
Sounds like a great idea to me!
It would fix the inconsistency I mentioned in another branch of this thread.
I'd use just "win32" and "win64" for short names of the architectures, since
we don't have i386-gcc, i386-clang and i386-tcc when all of them use glibc.
Once it is hidden inside dpkg's bowels, the triplet might be even
i586-i686-w32-w64-w128-but-really-w32-klaatu-verata-nikto-mingw-w42.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Attachment:
signature.asc
Description: Digital signature