Re: [lmi] error building libxml using install_msw.sh

[Vadim Zeitlin]

On Sun, 19 Jun 2011 16:54:49 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2011-06-18 14:18Z, Vadim Zeitlin wrote:
GC> > On Sat, 18 Jun 2011 12:07:17 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> [with thunderbird-3.1.10, "Reply to List" replies to Vadim personally;
GC> > GC> this time, I noticed it and fixed it]
GC> > 
GC> >  BTW, I intentionally reply to both the list and you personally as I 
notice
GC> > that the mailing list turnaround times can be quite long. Please let me
GC> > know if this bothers you and if you'd prefer that I reply to the list 
only.
GC> 
GC> That's fine with me. I'm grumbling only about the way thunderbird behaves; 
but
GC> I've learned to work around it. Let me know if you'd like to receive replies
GC> personally as well as on the list--that'd be speedier and no harder for me.

 I'm fine with receiving only mailing list replies and usually you don't
need anything urgent from me so I'd prefer to keep it this way unless you
really want to ensure that I get your message a.s.a.p.

GC> >  FWIW I committed my patches from a long dormant local git branch and now
GC> > you can build wxWidgets without any changes with i686-pc-mingw32-g++ 4.5.2
GC> > from Cygwin 1.7.
GC> 
GC> Good to hear. That's Charles Wilson's package: the mingw.org toolchain
GC> presented as a cross-compiler for Cygwin. There's supposed to be a 4.6.x
GC> release from mingw.org soon, and I'm sure Charles will update this package
GC> when that's released. AIUI, the DLL-decorations problem was fixed in 4.6 .

 Yes, I'll test it when it's released. FWIW I also built skeleton with this
compiler without too many problems (but with many warnings) but didn't
build lmi itself yet.

GC> If you've downloaded their stuff, would you mind checking which version
GC> of the Zope license they use? In FSF's opinion:
GC>   http://www.gnu.org/licenses/license-list.html
GC> 2.0 and 2.1 are compatible with the GPL, but 1.0 is not.

 Strangely enough I don't see any mention of Zope licence anywhere in
/usr/share/doc of my Cygwin installation but
http://sourceforge.net/apps/trac/mingw-w64/browser/trunk/COPYING starts
with

        With exception of certain parts that are prominently marked as being
        in the Public Domain, BSD, or LGPL this Software is provided under the
        Zope Public License (ZPL) Version 2.1.

so it looks like it should be fine.

GC> http://article.gmane.org/gmane.comp.gnu.mingw.user/36716/
GC> | The only time this is an issue, is when you have arranged for an OS
GC> | function to call YOUR client function:
GC> |
GC> | stack (in standard reverse order):
GC> | gcc: callback fn "foo" -- throws an exception....
GC> | OS:  some w32api func, calls the foo() callback function
GC> | gcc: main prog calls w32api func, and passes "&foo()" to it
GC> |
GC> | That's the only time this matters.
GC> | [...]
GC> | On the flip side, the problem case, where you pass a (gcc) callback
GC> | function to a win32 OS function is really rare, except in certain kinds
GC> | of GUI programming...and even then there are usually other ways to do it
GC> | so it can be coded around.
GC> 
GC> Is that case actually so rare with wxWidgets that it really can't occur
GC> in lmi?

 No, quite on the contrary, this happens all the time with wx because
whenever we get a Windows message we call Win32 ::DispatchMessage()
function that in turn calls our window procedure which eventually invokes
the user-defined event handler. And we do rely on any exceptions thrown by
the handlers being able to propagate through DispatchMessage() stack frame
so that they can be caught and passed to wxApp::OnExceptionInMainLoop().

 Now you could avoid overriding OnExceptionInMainLoop() and ensure that no
exception ever escapes any event handler. Or wxMSW could be modified to
actually do it for all the event handlers on its own as we had to do with
GTK where the event handlers are also called from C code compiled without
support for exceptions and so can't propagate through GTK layers and so
must be caught as soon as they're thrown. But the former would be tedious
to do while the latter would be not only tedious but also undesirable for
all wxMSW users not using gcc as we'd add extra unnecessary code to the
library (well, I guess we could make it conditional for gcc only...). In
any case right now LMI does rely on exceptions being able to propagate
through Windows code at least here.

 And I'm not sure there are no other places where this happens or at least
might happen too. It's possible that there are none but I'd have to spend
time on looking at wxMSW code carefully from an unaccustomed point of view
to confirm it.

GC> Another point in favor of MinGW-w64: if I understand this correctly:
GC>   
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/
GC> it looks like they host their own '-cygwin-' builds, in addition to
GC> offering them through the Cygwin mirror system. I can't readily see
GC> which exact gcc versions these tarballs represent, but I'd guess that
GC> they offer more than one. Do you know for sure?

 Unfortunately no. I'm actually really confused by their release system or
maybe lack thereof and was very glad to be able to simply install Cygwin
packages and not think about it. In any case I don't think you can rely on
them keeping the old releases indefinitely, seeing the amount of files they
have and their sizes I think they need to clean them regularly to avoid
running out of (generous but still existing) SourceForge quotas.

GC> >  It looks like all we need is to make available the current/fixed versions
GC> > of i686-w64-mingw32-g++ and related packages somewhere. Is it really such 
a
GC> > problem? In this day and age it's really not difficult to cheaply and
GC> > reliably host the necessary files at some publicly available URL, e.g.
GC> > using Amazon S3.
GC> 
GC> I'm hoping we'll find that mingw-w64.sourceforge.net already does this.

 I don't think they do currently.

GC> My biggest concern is preserving our ability to choose a gcc version that's
GC> not necessarily recent enough to be offered by the Cygwin installer.

 Sorry to be blunt but I have a strong feeling that we spend too much time
discussing this problem instead of simply putting the files we need
somewhere (maybe even directly in Savannah LMI file area -- as the install
script needs access to Savannah for the sources in any case, this seems as
reasonable place as any) and moving on.

 Regards,
VZ