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

[Vadim Zeitlin]

On Sat, 18 Jun 2011 12:07:17 +0000 Greg Chicares <address@hidden> wrote:

GC> [with thunderbird-3.1.10, "Reply to List" replies to Vadim personally;
GC> this time, I noticed it and fixed it]

 BTW, I intentionally reply to both the list and you personally as I notice
that the mailing list turnaround times can be quite long. Please let me
know if this bothers you and if you'd prefer that I reply to the list only.

GC> >  I think it was done quite some time ago and I actually tried using it to
GC> > build wxWidgets. It works (inasmuch as you disable DLL declarations which
GC> > are broken with 4.5, as you remember, and mean that by default linker runs
GC> > out of memory even with 8GB available (and I can't even blame myself for
GC> > not getting 16GB because it wouldn't even help as Cygwin is a 32 bit
GC> > process and so is limited to 2GB of RAM provided by Win32 to the user
GC> > processes anyhow)) but is very slow.

 FWIW I committed my patches from a long dormant local git branch and now
you can build wxWidgets without any changes with i686-pc-mingw32-g++ 4.5.2
from Cygwin 1.7.

GC> That example shows why I avoid relying on any compiler from Cygwin.
GC> 
GC> The mingw-gcc-{core,g++,fortran,objc}-4.5.2-1 package
GC>   http://cygwin.com/ml/cygwin/2011-06/msg00021.html
GC> is intended to prevent problems such as this 'libws2_32.a' issue:

 Reading the message above I wonder if I shouldn't be using mingw64-x86_64
version instead, I think mingw-w64.sf.net (misspelt in the original
message) might have brighter future than mingw.org. They also use SJLJ
(http://sourceforge.net/apps/trac/mingw-w64/wiki/Exception Handling) and I
just downloaded the Cygwin i686-w64-mingw32-g++ package and it does use
SJLJ as well. So this seems like the ideal candidate for us, doesn't it?
I'll test with it instead of i686-pc-mingw32-g++ unless you see any reason
to prefer the latter.

GC> But the current version is 4.5.2, and the earlier one that you tested
GC> was 4.5.1, and Cygwin offers only the two most recent versions of its
GC> packages. If we have a compiler that meets our needs, and they release
GC> a new one that doesn't, and subsequently update that new one, then we
GC> can't readily get back to the one we need. That's the problem.

 I agree. But OTOH I think in the long run it would be easier to solve the
problem than continuing to muddle through with MinGW/Cygwin hybrid we use
right now. The path-related problems are really, really painful.

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


GC> And it'll use dw2 exception handling, which may turn out to be
GC> a showstopper for lmi:

 I didn't think about this but it does look a serious problem :-(

GC> http://cygwin.com/ml/cygwin/2011-06/msg00021.html
GC> | OTOH, sjlj | is a requirement if you wish to catch exceptions that
GC> | unwind through 'foreign frames'

 I idly wonder why can't gcc use the same SEH mechanisms that all the other
Windows C++ (and C) compilers use. According to
http://gcc.gnu.org/wiki/WindowsGCCImprovements there was even an attempt to
use SEH in gcc but apparently it never got anywhere.

 BTW, while looking for information about this I also found that there was
a GSoC project in 2008 to allow propagating of DW2 exceptions through
foreign frames. Unfortunately it wasn't finished, see
http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008.


GC> >  Anyhow, for now I'm still stuck with the libws2_32.a issue. Right now I
GC> > really don't see any decent solution to this problem, can you think of
GC> > anything that I'm missing?
GC> 
GC> Intercept the libtool script after it's written but before it's executed,
GC> and use something like 'sed' to remove double slashes in paths?

 I don't see how could this work as the path is constructed dynamically.
The only idea I see is to filter out trailing slashes in -print-search-dirs
output. This would probably be feasible... Charles Wilson also gave another
idea at http://article.gmane.org/gmane.os.cygwin/127264 so I could try this
as well.


GC> Maybe we're at a crossroads. Let's suppose, perhaps too harshly, that:
GC> 
GC>  - Cygwin has gone off in a direction that breaks "identity mounts"
GC>      http://cygwin.com/ml/cygwin/2011-06/msg00226.html

 I don't think there is an intentional desire for breaking identity mounts
but it's certain that it's way too simple to completely break them
accidentally. And, of course, IMNSHO they're at least half-broken even now
(disabling dependencies support via "gcc -M" is really not acceptable, for
example). So I definitely think it would be wise to move away from
solutions relying on identity mounts.

GC>  - the insurance industry keeps paying MS for new OS versions that
GC>    continue to make Cygwin less reliable or harder to maintain
GC> 
GC>  - MinGW and Cygwin are committed to dw2-only exception handling, and
GC>    this makes their tools unacceptable for GUI work on the msw platform

 I don't think anybody will remove SJLJ exceptions support as long as
nothing better is available. And mingw64 folks seem to look forward to
implementing support for the standard SEH which would be even better.

GC>    (and maybe they won't fix the dll-decorations problem either)

 Apparently this should be fixed in 4.6. In the meanwhile, 4.5 seems to get
by fine using auto-import.

GC> Then our options for the long term are:
...
GC>  - do it all on GNU/Linux, which seems like the best option if we're
GC>    forced to make a radical change

 I have to wonder here if switching to GNU/Linux for the build environment
can really be simpler for your (non/less technical) users than having to
download compiler binaries from some place. IMO the latter is by far the
simplest solution.

 Regards,
VZ