On Tue, 29 Nov 2011 12:17:54 +, Wookey wrote:
> I know almost nothing about mingw* use and variants, but it does strike
> me that it just another cross-compiler, and choices about package
> names and triplets should be at least influenced by what we do for all
> the other cross-toolchains, mul
+++ Ron [2011-11-14 03:03 +1030]:
> On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > I thought it better to follow the MinGW-w64 project's recommendations,
> > including using their triplets.
>
> > I'll try a build with the old triplets to see how that goes, and to figure
> > out
On Mon, 28 Nov 2011 09:34:00 +0100, Fabian Greffrath
wrote:
> > To provide all the binaries in gcc-mingw32 it will have to depend on
> > {gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
> > compatibility symlinks you mention (and the usual /usr/share/doc
> > contents). It will pull
To provide all the binaries in gcc-mingw32 it will have to depend on
{gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
compatibility symlinks you mention (and the usual /usr/share/doc contents).
It will pull in mingw-w64-i686-dev indirectly, and binutils-mingw-w64-i686
too.
This s
On Fri, 25 Nov 2011 14:03:32 +0100, Fabian Greffrath
wrote:
> > probably generate more confusion with the similarity to mingw32. I'd vote
> > for mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the
> > following:
>
> Me too!
I'll go for that then, taking into account Simon's remark (so
On Fri, 25 Nov 2011 at 03:07:16 +0100, Stephen Kitt wrote:
> I'd vote for
> mingw-w64-i686 and mingw-w64-x86_64 in the end
It'll have to be x86-64 (or even x86.64) in package names, since _ isn't
allowed there, but the general principle seems OK.
There is precedent in the archive for replacing th
probably generate more confusion with the similarity to mingw32. I'd vote for
mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the following:
Me too!
How about the following base description:
MinGW-w64 provides a development and runtime environment for 32- and 64-bit
(x86 and x64)
On Thu, 24 Nov 2011 16:17:32 +0100, Fabian Greffrath
wrote:
> > 32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
> > Windows too; it seems the package description isn't sufficient).
>
> Yes, the package descriptions might need some improvement. This is how
> mingw-w64 intro
gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).
That's great news!
I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names
gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).
That's great news!
I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names
Hi Fabian,
On Fri, 11 Nov 2011 15:33:55 +0100, Fabian Greffrath
wrote:
> > The history has been explained by others. I've been working for a while on
> > dropping at least gcc-mingw32; see #644769 which tracks the various
> > packages build-depending on gcc-mingw32 and/or mingw32. There are only
On Mon, 14 Nov 2011 03:03:16 +1030, Ron wrote:
> On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > There is one major difference I know of: i686-pc-mingw32 (the official
> > MinGW triplet) builds with Dwarf2 exception handling, whereas the
> > -w64-mingw32 (the official MinGW-w64 t
On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote:
> > > As far as the naming is concerned, see #622276 for details. I've thought
> > > about splitting the packages up, with separate 32- and 64-bit targets, but
> > > I'm n
Hi Ron,
On Fri, 11 Nov 2011 07:36:28 +1030, Ron wrote:
> I was hoping you'd actually been cc'd on this :)
I was a few days behind debian-devel so I found out aboud the discussion
thanks to Fabian's bug report, which you will have received too ;-).
> On Thu, Nov 10, 2011 at 08:16:01PM +0100, Ste
Dear Stephen,
The history has been explained by others. I've been working for a while on
dropping at least gcc-mingw32; see #644769 which tracks the various packages
build-depending on gcc-mingw32 and/or mingw32. There are only three packages
left now; see #623400, #623402 and #623526. Patches a
On Thu, Nov 10, 2011 at 8:16 PM, Stephen Kitt wrote:
> I've thought
> about splitting the packages up, with separate 32- and 64-bit targets, but
> I'm not sure whether replacing and providing the mingw32 packages would be
> correct, since mingw-w64 isn't a drop-in replacement (the triplets are
>
Hi Stephen,
I was hoping you'd actually been cc'd on this :)
On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote:
> As far as the naming is concerned, see #622276 for details. I've thought
> about splitting the packages up, with separate 32- and 64-bit targets, but
> I'm not sure wheth
Hi Fabian (and all the other participants in this thread),
On Wed, 09 Nov 2011 13:33:14 +0100, Fabian Greffrath
wrote:
> Is there a principle behind all this or where can I help to clean this
> up? ;)
The history has been explained by others. I've been working for a while on
dropping at least g
On Thu, Nov 10, 2011 at 9:28 AM, Fabian Greffrath wrote:
> Am 09.11.2011 17:04, schrieb Pau Garcia i Quiles:
>>
>> Yes, that would be my advice. Unfortunately mingw32 is now too far
>> behind mingw-w64. The fork has become better than the original
>> project.
>
> I still love it for the MSYS bundl
Am 09.11.2011 17:04, schrieb Pau Garcia i Quiles:
Yes, that would be my advice. Unfortunately mingw32 is now too far
behind mingw-w64. The fork has become better than the original
project.
I still love it for the MSYS bundle, though.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debi
Thanks for your answers!
On Wed, Nov 9, 2011 at 2:16 PM, Simon McVittie wrote:
Does mingw[32] have any particular advantages over mingw-w64, I wonder?
Not that I know. mingw-w64's CRT is more complete (it includes LFS,
which mingw32 does not, for instance), includes more up-to-date
compilers
On Wed, Nov 9, 2011 at 5:04 PM, Fabian Greffrath wrote:
> So if I understand it correctly, it would be best to entirely drop mingw32,
> gcc-mingw32, mingw32-runtime and the other members of that family from
> Debian and concentrate on mingw-w64 (which then, as a bonus, could be split
> into packa
On Wed, Nov 9, 2011 at 2:16 PM, Simon McVittie wrote:
> Does mingw[32] have any particular advantages over mingw-w64, I wonder?
Not that I know. mingw-w64's CRT is more complete (it includes LFS,
which mingw32 does not, for instance), includes more up-to-date
compilers and handles threading bett
On Wed, Nov 09, 2011 at 01:33:14PM +0100, Fabian Greffrath wrote:
> is there a reason why we have both a mingw32 and a gcc-mingw32
> package in Debian? Both seem to contain the same, i.e. the GCC from
> the MinGW project (please note they dropped the "32" for a while),
> but the version in gcc-ming
On Wed, 09 Nov 2011 at 13:33:14 +0100, Fabian Greffrath wrote:
> is there a reason why we have both a mingw32 and a gcc-mingw32
> package in Debian? Both seem to contain the same, i.e. the GCC from
> the MinGW project (please note they dropped the "32" for a while),
> but the version in gcc-mingw32
Hi,
It's even more complex than that, actually:
mingw32 contains gcc 4.2.1 for 32-bit targets
gcc-mingw32 contains gcc 4.4.4 for 32-bit targets. IIRC is not an
official mingw.org release, this may be the reason why there is
mingw32 and gcc-mingw32.
gcc-mingw-w64 contains gcc 4.6 for both 32-bit
Dear -devel,
is there a reason why we have both a mingw32 and a gcc-mingw32 package
in Debian? Both seem to contain the same, i.e. the GCC from the MinGW
project (please note they dropped the "32" for a while), but the
version in gcc-mingw32 is newer than the one in mingw32.
For the 64-bit v
27 matches
Mail list logo
