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 11-10-2011, 08:06 PM
Ron
 
Default Bug#648306: The mingw* mess in Debian

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 whether replacing and providing the mingw32 packages would be
> correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> different). If that's not a problem then why not!

Ewww, why on earth did they change the triplet for the 32bit builds?
It's not actually a different architecture, or even a substantially
different toolchain.

If you've actually got this all building from the mainline sources now,
I'd have been all for folding this into the original mingw packages and
having some sort of sensible (if somewhat interrupted continuity for
people down that track ...

but if it's gratuitously incompatible, then I don't really know what to
do or think about that ... modulo pity for the people getting burned.

> The names for the 32-bit packages would probably be quite weird though since
> the upstream name is mingw-w64 (and I'd rather keep that in the package
> names...).

I'm not sure I really follow this, what am I missing here? What exactly
are you taking from 'upstream' in this case? My understanding was that
the toolchain was mainline gcc/binutils now, and all that the w64 folk
were providing was the runtime library? Is that wrong?

mingw.org has been basically dead for quite some time now, the 'developer'
list has been closed to the public and the only apparent work going on
was for native windows installers. They were even claiming that building
it for platforms other than windows was officially completely unsupported.
All the old-blood developers appear to have moved on to other things,
presumably because the 'hard parts' have all been mainlined now.

So sourcing the runtime from somewhere else now seems like a useful
proposition. But changing more than was really needed to do that does
make describing this as a "mess" look like a generous understatement ...

Is it really that bad, and if so is it really too late to back away
slowly and make this less disruptive to established users? It would
be nice to actually have an orderly 'upgrade' path through this rather
than an "everything is different now" paradigm shift. It is just a
toolchain after all. For a rather old and settled architecture.

Ron



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111110210628.GQ765@audi.shelbyville.oz">http://lists.debian.org/20111110210628.GQ765@audi.shelbyville.oz
 
Old 11-12-2011, 11:17 PM
Stephen Kitt
 
Default Bug#648306: The mingw* mess in Debian

Hi Ron,

On Fri, 11 Nov 2011 07:36:28 +1030, Ron <ron@debian.org> 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, 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 whether replacing and providing the mingw32 packages would be
> > correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> > different). If that's not a problem then why not!
>
> Ewww, why on earth did they change the triplet for the 32bit builds?
> It's not actually a different architecture, or even a substantially
> different toolchain.

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 triplets) build with SJLJ exception handling because
Dwarf2 doesn't work on Win64 and isn't compatible with DLLs built with
anything other than gcc. (See
https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
details.) There may be other non-political differences I'm not aware of.

> If you've actually got this all building from the mainline sources now,
> I'd have been all for folding this into the original mingw packages and
> having some sort of sensible (if somewhat interrupted continuity for
> people down that track ...
>
> but if it's gratuitously incompatible, then I don't really know what to
> do or think about that ... modulo pity for the people getting burned.

I could be wrong about this, but I don't believe it's gratuitously
incompatible. The thing is though that end-users are now used to the
-w64-mingw32 triplets.

> > The names for the 32-bit packages would probably be quite weird though
> > since the upstream name is mingw-w64 (and I'd rather keep that in the
> > package names...).
>
> I'm not sure I really follow this, what am I missing here? What exactly
> are you taking from 'upstream' in this case? My understanding was that
> the toolchain was mainline gcc/binutils now, and all that the w64 folk
> were providing was the runtime library? Is that wrong?

That's correct, so the only really upstream package is mingw-w64 which
provides the headers and libraries required to target Windows (it's not even
a runtime library since there is no non-gcc runtime library). The MinGW-w64
developers do submit patches against binutils and gcc now and again, so in a
sense they're still providing the toolchain, they're just upstreaming
everything instead of shipping patches.

> mingw.org has been basically dead for quite some time now, the 'developer'
> list has been closed to the public and the only apparent work going on
> was for native windows installers. They were even claiming that building
> it for platforms other than windows was officially completely unsupported.
> All the old-blood developers appear to have moved on to other things,
> presumably because the 'hard parts' have all been mainlined now.
>
> So sourcing the runtime from somewhere else now seems like a useful
> proposition. But changing more than was really needed to do that does
> make describing this as a "mess" look like a generous understatement ...
>
> Is it really that bad, and if so is it really too late to back away
> slowly and make this less disruptive to established users? It would
> be nice to actually have an orderly 'upgrade' path through this rather
> than an "everything is different now" paradigm shift. It is just a
> toolchain after all. For a rather old and settled architecture.

I thought it better to follow the MinGW-w64 project's recommendations,
including using their triplets. Because people still encounter bugs fairly
regularly (see the bug trackers at
https://sourceforge.net/tracker/?group_id=202880 and the mailing list
archives), I believe we're better off if we can easily get support from
upstream, and they're more inclined to help us out if we follow their
guidelines.

I'll try a build with the old triplets to see how that goes, and to figure
out what kind of upgrade path we can provide...

Regards,

Stephen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111113011743.38344eb0@sk2.org">http://lists.debian.org/20111113011743.38344eb0@sk2.org
 
Old 11-13-2011, 03:33 PM
Ron
 
Default Bug#648306: The mingw* mess in Debian

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 not sure whether replacing and providing the mingw32 packages would be
> > > correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> > > different). If that's not a problem then why not!
> >
> > Ewww, why on earth did they change the triplet for the 32bit builds?
> > It's not actually a different architecture, or even a substantially
> > different toolchain.
>
> 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 triplets) build with SJLJ exception handling because
> Dwarf2 doesn't work on Win64 and isn't compatible with DLLs built with
> anything other than gcc. (See
> https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
> details.)

Actually, that's not quite true. At least for the case we care about here
anyway ... The dwarf2 handling never really was quite finished, and never
really did work quite right. That might have changed now, but the mingw32
toolchain we are migrating from here is also an SJLJ build ...

The 'official MinGW' triplet you quote above was also a gratuitous new
change made 'fairly recently' by the new folks there. From what I saw when
they did that it was mostly an arbitrary choice made by new people who had
no idea that we needed the msvc qualifier because there was *also* a crtdll
build variant way back in ancient times, which existed before the msvc builds
were actually reliable, and which was still in use when this toolchain was
first uploaded to Debian.

They then went on to foam about distros using i586-mingw32msvc, which had
been in use for more than 10 years before those people ever came along ...
Which is about the point that I stopped hoping for sane new releases from
those people


> > If you've actually got this all building from the mainline sources now,
> > I'd have been all for folding this into the original mingw packages and
> > having some sort of sensible (if somewhat interrupted continuity for
> > people down that track ...
> >
> > but if it's gratuitously incompatible, then I don't really know what to
> > do or think about that ... modulo pity for the people getting burned.
>
> I could be wrong about this, but I don't believe it's gratuitously
> incompatible. The thing is though that end-users are now used to the
> -w64-mingw32 triplets.

Well, that's why it's a horrid mess The dead mingw fork changed it for
no good reason, and so did the w64 fork ...

Saying "end users are now used to the new one", isn't much of a consolation
to the people who've been using this since the 1990's without having that
sort of thing inflicted on them for no actual gain. And I'll put a beer on
there being far more of those than there are people already on the -w64 train.

It's kind of like saying "end users are now used to GNOME 3" ...
And sadly I think it's probably going to end about as well


> > > The names for the 32-bit packages would probably be quite weird though
> > > since the upstream name is mingw-w64 (and I'd rather keep that in the
> > > package names...).
> >
> > I'm not sure I really follow this, what am I missing here? What exactly
> > are you taking from 'upstream' in this case? My understanding was that
> > the toolchain was mainline gcc/binutils now, and all that the w64 folk
> > were providing was the runtime library? Is that wrong?
>
> That's correct, so the only really upstream package is mingw-w64 which
> provides the headers and libraries required to target Windows (it's not even
> a runtime library since there is no non-gcc runtime library). The MinGW-w64
> developers do submit patches against binutils and gcc now and again, so in a
> sense they're still providing the toolchain, they're just upstreaming
> everything instead of shipping patches.

Right, I didn't mean to say they weren't also contributing to the toolchain,
just that we aren't taking patches directly from them for this. It's the
same mainline gcc that everyone else has -- and which doesn't really have any
-w64 connotations of its own as such. So it might be better to avoid making
that association ourselves, to avoid the need for yet another rename if this
later goes and forks again.


> > mingw.org has been basically dead for quite some time now, the 'developer'
> > list has been closed to the public and the only apparent work going on
> > was for native windows installers. They were even claiming that building
> > it for platforms other than windows was officially completely unsupported.
> > All the old-blood developers appear to have moved on to other things,
> > presumably because the 'hard parts' have all been mainlined now.
> >
> > So sourcing the runtime from somewhere else now seems like a useful
> > proposition. But changing more than was really needed to do that does
> > make describing this as a "mess" look like a generous understatement ...
> >
> > Is it really that bad, and if so is it really too late to back away
> > slowly and make this less disruptive to established users? It would
> > be nice to actually have an orderly 'upgrade' path through this rather
> > than an "everything is different now" paradigm shift. It is just a
> > toolchain after all. For a rather old and settled architecture.
>
> I thought it better to follow the MinGW-w64 project's recommendations,
> including using their triplets. Because people still encounter bugs fairly
> regularly (see the bug trackers at
> https://sourceforge.net/tracker/?group_id=202880 and the mailing list
> archives), I believe we're better off if we can easily get support from
> upstream, and they're more inclined to help us out if we follow their
> guidelines.

Does this actually successfully build everything that the old mingw toolchain
did now? There were some reports of miscompiles with the -w64 packages that
Robert first made, but I don't offhand recall which projects that was with.
That was one of the main reasons we didn't immediately kill the old toolchain.


> I'll try a build with the old triplets to see how that goes, and to figure
> out what kind of upgrade path we can provide...

Cool. Despite my grumbling about how people who paid no attention to the
history are busy reinventing pain that we were supposed to be long past,
I am actually really grateful for all the work you've put in to sorting
this out.

If things are going to break, it would be really nice to get *everyone*
with a stake in this to break it the same way and then promise not to
break it again. It's one thing for random libraries to fork with no
attachment to the established users and fiddle with things incompatibly
just to 'make their mark' on it. But that's not really something we
should be doing with toolchains for old architectures.

Cheers,
Ron



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111113163316.GV765@audi.shelbyville.oz">http://lists.debian.org/20111113163316.GV765@audi.shelbyville.oz
 
Old 11-19-2011, 02:23 PM
Stephen Kitt
 
Default Bug#648306: The mingw* mess in Debian

On Mon, 14 Nov 2011 03:03:16 +1030, Ron <ron@debian.org> 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 triplets) build with SJLJ exception
> > handling because Dwarf2 doesn't work on Win64 and isn't compatible with
> > DLLs built with anything other than gcc. (See
> > https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
> > details.)
>
> Actually, that's not quite true. At least for the case we care about here
> anyway ... The dwarf2 handling never really was quite finished, and never
> really did work quite right. That might have changed now, but the mingw32
> toolchain we are migrating from here is also an SJLJ build ...

OK, thanks for the info - I hadn't actually checked the Debian packages. I do
know that some MinGW-build packages "in the wild" use libgcc_s_dw2-1.dll
rather than libgcc_s_sjlj-1.dll as provided by gcc-mingw-w64; but that's
neither here nor there as far as the migration we're discussing is concerned!

> The 'official MinGW' triplet you quote above was also a gratuitous new
> change made 'fairly recently' by the new folks there. From what I saw when
> they did that it was mostly an arbitrary choice made by new people who had
> no idea that we needed the msvc qualifier because there was *also* a crtdll
> build variant way back in ancient times, which existed before the msvc
> builds were actually reliable, and which was still in use when this
> toolchain was first uploaded to Debian.
>
> They then went on to foam about distros using i586-mingw32msvc, which had
> been in use for more than 10 years before those people ever came along ...
> Which is about the point that I stopped hoping for sane new releases from
> those people

I knew the history of the mingw32msvc name, but not that the change was
gratuitous... Looking around the Internet it seems i586-mingw32msvc is still
in use (if only because of "old" instructions using Debian's own mingw32
packages), and the new mingw-w64 triplets are referenced as well, but there's
not much sign of the new mingw triplets.

[snip]
> > I thought it better to follow the MinGW-w64 project's recommendations,
> > including using their triplets. Because people still encounter bugs fairly
> > regularly (see the bug trackers at
> > https://sourceforge.net/tracker/?group_id=202880 and the mailing list
> > archives), I believe we're better off if we can easily get support from
> > upstream, and they're more inclined to help us out if we follow their
> > guidelines.
>
> Does this actually successfully build everything that the old mingw
> toolchain did now? There were some reports of miscompiles with the -w64
> packages that Robert first made, but I don't offhand recall which projects
> that was with. That was one of the main reasons we didn't immediately kill
> the old toolchain.

There's still one issue I know of; see #635439. None of the packages in
Debian caused much trouble migrating to mingw-w64; if I remember correctly
the main issues were related to switching to gcc 4.6 rather than mingw-w64
itself. In software not packaged for Debian I've come across problems where
the software being built defined stuff from Windows which wasn't directly
supported in mingw32 but is now in mingw-w64; that's usually easily worked
around.

> > I'll try a build with the old triplets to see how that goes, and to figure
> > out what kind of upgrade path we can provide...
>
> Cool. Despite my grumbling about how people who paid no attention to the
> history are busy reinventing pain that we were supposed to be long past,
> I am actually really grateful for all the work you've put in to sorting
> this out.

You're welcome!

> If things are going to break, it would be really nice to get *everyone*
> with a stake in this to break it the same way and then promise not to
> break it again. It's one thing for random libraries to fork with no
> attachment to the established users and fiddle with things incompatibly
> just to 'make their mark' on it. But that's not really something we
> should be doing with toolchains for old architectures.

I tried a build using i586-mingw32msvc, and it worked; things also work if I
just add i586-mingw32msvc- links to the i686-w64-mingw- binaries.

Do you think it would be OK to keep the mingw-w64 packages as is (to make
upstream support easier - they're the only "alive" upstream), and have
mingw32 replacement packages with symlinks as above?

Regards,

Stephen
 
Old 11-29-2011, 11:17 AM
Wookey
 
Default Bug#648306: The mingw* mess in Debian

+++ 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 what kind of upgrade path we can provide...
>
> Cool. Despite my grumbling about how people who paid no attention to the
> history are busy reinventing pain that we were supposed to be long past,
> I am actually really grateful for all the work you've put in to sorting
> this out.
>
> If things are going to break, it would be really nice to get *everyone*
> with a stake in this to break it the same way and then promise not to
> break it again.

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, multiarch considerations and
dpkg-architecture support.

This was discussed a long time ago on the debian-embedded list and
this page covers using dpkg-architecture and dpkg-cross to help with
cross-building debian-style for mingw32:
http://wiki.njh.eu/Cross_Compiling_for_Win32 (It predates multiarch
but the fundamentals are there).

Would it be useful for dpkg to know about w32-i386 and thus to be able
to use all the dpkg-cross and/or multi-arch machinery to help when
crossbuilding for win32? If so then is there anything in what you are
doing that gets in the way of this?

Feel free to ignore me if this is just crazy-talk, but I thought this
should at least be mentionned in case it had not been considered, as
now seems like a good time to line up the necessary triplet-names,
arch names, multiarch paths etc.

I'm happy to discuss this further if anyone cares.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129121754.GB28838@dream.aleph1.co.uk">http://lists.debian.org/20111129121754.GB28838@dream.aleph1.co.uk
 
Old 11-29-2011, 08:43 PM
Stephen Kitt
 
Default Bug#648306: The mingw* mess in Debian

On Tue, 29 Nov 2011 12:17:54 +0000, Wookey <wookey@wookware.org> 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, multiarch considerations and
> dpkg-architecture support.
>
> This was discussed a long time ago on the debian-embedded list and
> this page covers using dpkg-architecture and dpkg-cross to help with
> cross-building debian-style for mingw32:
> http://wiki.njh.eu/Cross_Compiling_for_Win32 (It predates multiarch
> but the fundamentals are there).
>
> Would it be useful for dpkg to know about w32-i386 and thus to be able
> to use all the dpkg-cross and/or multi-arch machinery to help when
> crossbuilding for win32? If so then is there anything in what you are
> doing that gets in the way of this?

The specifics regarding mingw-w64 have been discussed in the past; there's
an open bug against dpkg at http://bugs.debian.org/606825 which includes part
of the discussion. The result there was that we'd use mingw64...

I haven't taken care of all that yet; I'm waiting for the dust to settle
around multiarch before integrating cross-compiler stuff following the same
ideas (Steve Langasek mentioned a while back that the first priority was to
get multiarch working, without considering cross-compiler issues
particularly, even though there are similarities).

In any case what we've discussed so far in this thread is compatible with the
discussion in the above-mentioned bug.

Regards,

Stephen
 

Thread Tools




All times are GMT. The time now is 08:41 AM.

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