FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-22-2011, 09:04 PM
Stephen Kitt
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

Hello,

Now that multiarch is here, I've been wondering whether and how it applies to
cross-compiler libraries for non-Debian architectures, for example Microsoft
Windows (I'm the new maintainer of mingw-w64). As I understand it, multiarch
wasn't intended for non-Debian architectures, and this is (indirectly)
reflected in policy (9.1.1 point 3 for example).

It seems to me though that it would be nice to follow the multiarch directory
structure for cross-compilers to non-Debian architectures (basically,
anything for which there is no valid "Architecture" field value for a Debian
package). 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, and thus isn't policy compliant either since section 9.1.1
is based on the FHS).

Unfortunately this appears to go against policy 9.1.1, which forbids packages
installing files into triplet-based directories under /usr/lib other
than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm
thinking of aren't usable on any Debian architecture, they're provided as
"Architecture: all" packages and don't have a corresponding
DEB_HOST_MULTIARCH triplet.

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...)

Policy also doesn't mention /usr/include/<triplet>; I saw that possibility
referred to in http://bugs.debian.org/542865.

I'd appreciate your thoughts!

Regards,

Stephen

PS. I realise some may find it odd to spend time on Windows support in
Debian, but it does come in handy, for instance for newer versions of Wine,
or for Windows versions of some tools used to install Debian from a Windows
environment.
 
Old 04-23-2011, 12:40 AM
Adam Borowski
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Fri, Apr 22, 2011 at 11:04:59PM +0200, Stephen Kitt wrote:
> Hello,
>
> Now that multiarch is here, I've been wondering whether and how it applies to
> cross-compiler libraries for non-Debian architectures, for example Microsoft
> Windows (I'm the new maintainer of mingw-w64).

> It seems to me though that it would be nice to follow the multiarch directory
> structure for cross-compilers to non-Debian architectures

Sounds like a great idea.

> (basically, anything for which there is no valid "Architecture" field
> value for a Debian package). 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

Such dirs cannot include the compiler's name, since there are multiple
compilers for the architecture. Binaries compiled with
i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI.

Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns
i486-linux-gnu yet the arch triplet is i386-linux-gnu.

Mismatched triplets would make these binaries have effectively different
architectures.

> Unfortunately this appears to go against policy 9.1.1, which forbids packages
> installing files into triplet-based directories under /usr/lib other
> than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm
> thinking of aren't usable on any Debian architecture, they're provided as
> "Architecture: all" packages and don't have a corresponding
> DEB_HOST_MULTIARCH triplet.
>
> 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.

What about:
`Architecture: all' matches all triplets.

> Policy also doesn't mention /usr/include/<triplet>; I saw that possibility
> referred to in http://bugs.debian.org/542865.

Uhh... this looks like a nasty omission to me. If package libfoo-dev
differs between architectures, without that dir there's no possibility to
install it for multiple architectures at once. Having to reinstall headers
before every compilation is Not Funny.

> PS. I realise some may find it odd to spend time on Windows support in
> Debian, but it does come in handy, for instance for newer versions of Wine,
> or for Windows versions of some tools used to install Debian from a Windows
> environment.

Quite a few projects require a POSIX environment to build, this means either
msys, cygwin or cross-compilation. Msys is too minimal, cygwin too quirky,
which leaves Debian as the best choice. A good thing


--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110423004051.GA24193@angband.pl">http://lists.debian.org/20110423004051.GA24193@angband.pl
 
Old 04-23-2011, 03:25 AM
Paul Wise
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sat, Apr 23, 2011 at 8:40 AM, Adam Borowski <kilobyte@angband.pl> wrote:

>> Policy also doesn't mention /usr/include/<triplet>; I saw that possibility
>> referred to in http://bugs.debian.org/542865.
>
> Uhh... this looks like a nasty omission to me. *If package libfoo-dev
> differs between architectures, without that dir there's no possibility to
> install it for multiple architectures at once. *Having to reinstall headers
> before every compilation is Not Funny.

I always thought headers that differ between architectures should be
in /usr/lib somewhere.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikp1sOm_AsCd0e77hirCL6CRR3SCA@mail.gmail.com ">http://lists.debian.org/BANLkTikp1sOm_AsCd0e77hirCL6CRR3SCA@mail.gmail.com
 
Old 04-23-2011, 08:09 AM
Luca Bruno
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

Stephen Kitt scrisse:

> 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...)
>
> Policy also doesn't mention /usr/include/<triplet>; I saw that
> possibility referred to in http://bugs.debian.org/542865.
> I'd appreciate your thoughts!

While the wording may be refined for the final patch to policy, your
proposed idea is good. Have you already opened a bug to track it?

> PS. I realise some may find it odd to spend time on Windows support in
> Debian, but it does come in handy, for instance for newer versions of
> Wine, or for Windows versions of some tools used to install Debian
> from a Windows environment.

No need to feel alone in the dark, other compilers for bare-bone mcu
are in the same conditions. avr and msp430 (experimental only right now)
tool-chains will benefits from your proposal.

Cheers, Luca

--
.'`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S. | lucab (AT) debian.org
`. `'` | GPG Key ID: 3BFB9FB3
`- http://www.debian.org | Debian GNU/Linux Developer
 
Old 04-23-2011, 10:05 AM
Jonathan Nieder
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

Hi,

Adam Borowski wrote:

> Such dirs cannot include the compiler's name, since there are multiple
> compilers for the architecture. Binaries compiled with
> i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI.
>
> Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns
> i486-linux-gnu yet the arch triplet is i386-linux-gnu.

IIUC then the GNU triplet includes the choice of C library because
binaries (e.g., libraries) compiled against mingw32 and mingw-w64
cannot be linked (i.e., they do not share ABI). Though I could easily
be wrong.

IIRC according to the multiarch spec, paths in Debian use "simplified"
triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386.
Including so much unnecessary detail about the default instruction set
in the triplet is unusual (I know of no example other than x86). As
you mention, in the ix86 case it causes problems so we work around it.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110423100506.GA1500@elie">http://lists.debian.org/20110423100506.GA1500@elie
 
Old 04-23-2011, 10:29 AM
Goswin von Brederlow
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

Stephen Kitt <steve@sk2.org> writes:

> Hello,
>
> Now that multiarch is here, I've been wondering whether and how it applies to
> cross-compiler libraries for non-Debian architectures, for example Microsoft
> Windows (I'm the new maintainer of mingw-w64). As I understand it, multiarch
> wasn't intended for non-Debian architectures, and this is (indirectly)
> reflected in policy (9.1.1 point 3 for example).
>
> It seems to me though that it would be nice to follow the multiarch directory
> structure for cross-compilers to non-Debian architectures (basically,
> anything for which there is no valid "Architecture" field value for a Debian
> package). 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, and thus isn't policy compliant either since section 9.1.1
> is based on the FHS).
>
> Unfortunately this appears to go against policy 9.1.1, which forbids packages
> installing files into triplet-based directories under /usr/lib other
> than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm
> thinking of aren't usable on any Debian architecture, they're provided as
> "Architecture: all" packages and don't have a corresponding
> DEB_HOST_MULTIARCH triplet.
>
> 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.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874o5pfegc.fsf@frosties.localnet">http://lists.debian.org/874o5pfegc.fsf@frosties.localnet


Sat Apr 23 12:30:01 2011
Return-path: <gentoo-dev+bounces-45383-tom=linux-archive.org@lists.gentoo.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sat, 23 Apr 2011 12:13:30 +0300
Received: from pigeon.gentoo.org ([208.92.234.80]:40670 helo=lists.gentoo.org)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <gentoo-dev+bounces-45383-tom=linux-archive.org@lists.gentoo.org>)
id 1QDYuA-0002LZ-TF
for tom@linux-archive.org; Sat, 23 Apr 2011 12:13:30 +0300
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6F75B1C05C;
Sat, 23 Apr 2011 10:30:59 +0000 (UTC)
X-Original-To: gentoo-dev@lists.gentoo.org
Delivered-To: gentoo-dev@lists.gentoo.org
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 0DD161C033
for <gentoo-dev@lists.gentoo.org>; Sat, 23 Apr 2011 10:29:00 +0000 (UTC)
Received: from [192.168.1.101] (hnvr-4d07ac39.pool.mediaWays.net [77.7.172.57])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: chithanh)
by smtp.gentoo.org (Postfix) with ESMTPSA id 39A2C1B4028
for <gentoo-dev@lists.gentoo.org>; Sat, 23 Apr 2011 10:28:59 +0000 (UTC)
Message-ID: <4DB2A9CD.7010708@gentoo.org>
Date: Sat, 23 Apr 2011 12:28:29 +0200
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?=
<chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.18) Gecko/20110403 Gentoo/2.0.13 SeaMonkey/2.0.13
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on
packages from overlays?
References: <4DB26C3C.8090602@gentoo.org>
In-Reply-To: <4DB26C3C.8090602@gentoo.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Eray Aslan schrieb:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.

I understand that the push to remove old-style virtuals from the main
tree is because they cause headaches for the package managers during
dependency calculation. I also understand that existing EAPIs will not
be amended to forbid old-style virtuals.

Would it make sense to do the following:
(1) make all new-style virtuals additionally depend on an old-style
virtual (a new category might be appropriate)
(2) ebuilds in overlays can PROVIDE the old-style virtual
(3) in a future EAPI, package managers are allowed to ignore the
old-style virtual dependency for packages which are not already installed

If directly including installed old-style virtual packages in the
dependency calculations is not feasible, (3) could be implemented
through modifying package.provided like it is already done for
package.{keywords,mask,use} after profile/ updates


Regards,
Chi-Thanh Christopher Nguyen
 
Old 04-23-2011, 02:38 PM
Adam Borowski
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote:
> Hi,
>
> Adam Borowski wrote:
>
> > Such dirs cannot include the compiler's name, since there are multiple
> > compilers for the architecture. Binaries compiled with
> > i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI.
> >
> > Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns
> > i486-linux-gnu yet the arch triplet is i386-linux-gnu.
>
> IIUC then the GNU triplet includes the choice of C library because
> binaries (e.g., libraries) compiled against mingw32 and mingw-w64
> cannot be linked (i.e., they do not share ABI). Though I could easily
> be wrong.

Note that the triplets used by mingw-w64 were carefully chosen to produce as
much confusion as possible. The two architectures: win32 and win64 have
both "w32" and "w64" in the name:
* i686-w64-mingw32
* x86_64-w64-mingw32

The former is ABI-compatible not only with i586-mingw32msvc but also with
real msvc. I just tried all combinations of these three, even including
malloc()ing from an object compiled with one and free()ing from another.

Everything seems to work fine [1].


This is for C. C++ between MSVC10 and mingw32 is not ABI-compatible, but
even gcc breaks compatibility there completely every a few releases
(remember -c102 in gcc-4.0?) and in minor points more often. So does MSVC.
Our two mingw32 versions seem to be compatible with each other, though.


> IIRC according to the multiarch spec, paths in Debian use "simplified"
> triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386.
> Including so much unnecessary detail about the default instruction set
> in the triplet is unusual (I know of no example other than x86). As
> you mention, in the ix86 case it causes problems so we work around it.

Distinguishing between two ABI-compatible compilers would be even worse.
Fortunately, nothing started using these names yet, so it's a perfect moment
to discuss a common arch name.

Currently, the following packages use i586-mingw32msvc:
* gcc-mingw32
* mingw32
* mingw32-binutils
* mingw32-ocaml
* mingw32-runtime
* nsis

There's no need to use the same triplet for multiarch as for compiler,
so the new path might use something else. I don't care what, as long as
it's consistent between all of win32 in Debian.


[1]. Googling around, I see there's a problem with bitfields in structures
which has been fixed only in gcc-4.6, so it's "almost fine". It seems that
MSVC ABI compatibility is one of goals for mingw. Anyway, it's not like
Debian can ship anything compiled with real MSVC, so if you think that
"almost compatible" is not good enough, the triplet can include -mingw
rather than -msvc.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 04-23-2011, 02:51 PM
Adam Borowski
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

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.
 
Old 04-23-2011, 09:19 PM
Stephen Kitt
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sat, 23 Apr 2011 16:51:53 +0200, Adam Borowski <kilobyte@angband.pl> wrote:
> On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote:
> > 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.

So if I understand things correctly that would mean using /usr/lib/win32
and /usr/lib/win64, regardless of the binutils/gcc triplet (which is fine as
far as I'm concerned - all I'm wary of is changing the gcc triplet used
upstream, see http://bugs.debian.org/622276 - obviously, Adam, you know about
this, but others probably don't).

Goswin, I take it you're advocating building _win32.deb packages (or
something similar) - is that correct? I didn't even realise that would be
possible without appropriate buildds... I know about “dpkg-buildpackage -a”
or “pdebuild --architecture” for local rebuilds, but would rebuilding such a
package be possible on the existing buildd network?

Regards,

Stephen
 
Old 04-23-2011, 09:36 PM
Stephen Kitt
 
Default Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sat, 23 Apr 2011 16:38:57 +0200, Adam Borowski <kilobyte@angband.pl> wrote:
> On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote:
> > IIUC then the GNU triplet includes the choice of C library because
> > binaries (e.g., libraries) compiled against mingw32 and mingw-w64
> > cannot be linked (i.e., they do not share ABI). Though I could easily
> > be wrong.
>
> Note that the triplets used by mingw-w64 were carefully chosen to produce as
> much confusion as possible. The two architectures: win32 and win64 have
> both "w32" and "w64" in the name:
> * i686-w64-mingw32
> * x86_64-w64-mingw32

“were carefully chosen” is perhaps a slight exaggeration (see
http://bugs.debian.org/622276 for my understanding of how these triplets
ended up being used), but I do admit it can be confusing.

> The former is ABI-compatible not only with i586-mingw32msvc but also with
> real msvc. I just tried all combinations of these three, even including
> malloc()ing from an object compiled with one and free()ing from another.
>
> Everything seems to work fine [1].

I can confirm this too, as far as I've been able to determine the output of
gcc-mingw32 in Debian is compatible with that of gcc-mingw-w64 when
targeting Win32.

> This is for C. C++ between MSVC10 and mingw32 is not ABI-compatible, but
> even gcc breaks compatibility there completely every a few releases
> (remember -c102 in gcc-4.0?) and in minor points more often. So does MSVC.
> Our two mingw32 versions seem to be compatible with each other, though.

I haven't checked this but I'll take your word for it.

> > IIRC according to the multiarch spec, paths in Debian use "simplified"
> > triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386.
> > Including so much unnecessary detail about the default instruction set
> > in the triplet is unusual (I know of no example other than x86). As
> > you mention, in the ix86 case it causes problems so we work around it.
>
> Distinguishing between two ABI-compatible compilers would be even worse.
> Fortunately, nothing started using these names yet, so it's a perfect moment
> to discuss a common arch name.
>
> Currently, the following packages use i586-mingw32msvc:
> * gcc-mingw32
> * mingw32
> * mingw32-binutils
> * mingw32-ocaml
> * mingw32-runtime
> * nsis

I'm hoping the mingw-w64 set of packages (mingw-w64, binutils-mingw-w64 and
gcc-mingw-w64) will be good enough to replace gcc-mingw32, mingw32,
mingw32-binutils and mingw32-runtime. I originally started working on
mingw-w64 to get wine-gecko into the archive and thus allow wine packaging to
resume, but it seemed to me a good time as well to work on cleaning up the
whole set of mingw packages in Debian. I've sent patches to allow most of the
reverse-build-dependencies of mingw32 or gcc-mingw32 to build using mingw-w64
(nsis, autorun4linuxcd, cpio, gzip, gnupg and win32-loader so far), and I'm
working on the remaining two (mingw32-ocaml and libreoffice).

Completing all this would mean the i586-mingw32msvc target could be forgotten
entirely; no one outside Debian uses it (any more), upstream and others have
switched to the -w64-mingw32 suffix. (See also http://bugs.debian.org/606825
for extensive discussion and a first patch for dpkg support.)

> There's no need to use the same triplet for multiarch as for compiler,
> so the new path might use something else. I don't care what, as long as
> it's consistent between all of win32 in Debian.

That's fine by me, regardless of whether mingw-w64 ends up being “all of
win32 in Debian” or not!

Regards,

Stephen
 

Thread Tools




All times are GMT. The time now is 04:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org