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

[Greg Chicares]

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

On 2011-06-17 18:36Z, Vadim Zeitlin wrote:
> On Fri, 17 Jun 2011 18:01:04 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Then we'd rely on Cygwin's gcc toolchain. One problem is that they
> GC> update packages asynchronously, keeping only one earlier version
> GC> and deleting everything older than that.
[...]
> GC> But I think Charles Wilson has just released a MinGW cross-compiler
> GC> for Cygwin,
> 
>  I think it was done quite some time ago and I actually tried using it to
> build wxWidgets. It works (inasmuch as you disable DLL declarations which
> are broken with 4.5, as you remember, and mean that by default linker runs
> out of memory even with 8GB available (and I can't even blame myself for
> not getting 16GB because it wouldn't even help as Cygwin is a 32 bit
> process and so is limited to 2GB of RAM provided by Win32 to the user
> processes anyhow)) but is very slow.

That example shows why I avoid relying on any compiler from Cygwin.

The mingw-gcc-{core,g++,fortran,objc}-4.5.2-1 package
  http://cygwin.com/ml/cygwin/2011-06/msg00021.html
is intended to prevent problems such as this 'libws2_32.a' issue:

http://article.gmane.org/gmane.comp.gnu.mingw.user/36681
| Note that it IS possible to use our native MinGW gcc from within a
| cygwin environment -- BUT there are two drawbacks: [...]
| no automatic path translation, so you have to jump through special hoops
| (like so called "unity mounts" -- use google) in order to "fool" MinGW
| gcc.exe into accepting unix paths and interpreting them correctly (as
| DOS paths!).  There are also other 'gotchas'.
|
| This is a BIG pain, but many people have done it for years.  However,
| with the new cygwin-hosted cross compiler, it's much more streamlined to
| simply use THAT, if you want to stay in the cygwin world.

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

Of course, we could save the binaries ourselves, somewhere. Or we could
use the "Cygwin time machine" and hope it works. Or we could save the
sources (as modified for Cygwin) and rebuild the compiler ourselves.
Maybe those methods would work; or maybe they would fail if the Cygwin
"kernel" changes in an incompatible way. But, even if they did work,
they're not suitable for us: we want a simple, automated way for users
who aren't programmers to grab the environment they need to build lmi.
The compilers from mingw.org are suitable because, crucially, they keep
historical binaries available almost forever.

> GC> but if we're going to consider any change along these lines, then
> GC> moving to gcc-4.x is the first step.
> 
>  I can test building LMI with Cygwin i686-pc-mingw32-g++ 4.5 if you're
> interested (so far I only tried it with various versions of MinGW g++ 4.5
> but never finished because of various MinGW/Cygwin conflicts on my main
> machine).

Sure, if you think that's a good idea. I suppose it'll get you past the
stated conflicts. However, it may introduce new difficulties due to
newlib. And it'll use dw2 exception handling, which may turn out to be
a showstopper for lmi:

http://cygwin.com/ml/cygwin/2011-06/msg00021.html
| Most importantly, the use of --disable-sjlj-exceptions means that our
| MinGW cross compiler (and MinGW.org's "native" compiler) use dw2
| exception handling, rather than sjlj.  MOST other platforms' mingw
| cross compilers (such as Fedora or Mandriva) seem to use sjlj instead.
| Thus, products generated using those cross compilers are not compatible
| with MinGW.org's compiler, while those generated using our cross
| compiler ARE compatible.  However, the downside is that maintaining
| compatibility with MinGW.org means we are INcompatible with Fedora and
| Mandriva (etc) mingw cross compilers.
[...]
| OTOH, sjlj
| is a requirement if you wish to catch exceptions that unwind through
| 'foreign frames' -- that is, you pass a callback function to a Win32 API
| function, and expect to catch any exceptions it may throw, even though
| those exceptions must unwind "through" the Win32 API (i.e. "foreign")
| frame.  So, there are advantages and drawbacks to each approach:
| mingw64.sf chose one way, MinGW.org chose the other.  Let a thousand
| flowers bloom.

I suppose a mingw-gcc-{core,g++,fortran,objc}-4.5.2-1 experiment would
identify various gcc-3-isms in lmi that we could fix, and would let us
see whether dw2 exception handling is unacceptable for lmi. And it would
create an unwelcome opportunity to deal with the "DLL declarations" issue
mentioned above. But I doubt we'd be able to use this in production--the
dw2 issue just sounds like a fatal obstacle--but "the work of science is
to substitute facts for appearances and demonstrations for impressions"
[Ruskin] and it'd be good to find out for sure.

> GC> Besides, we use zsh for other tasks as well as building software.
> 
>  I definitely prefer using Cygwin for convenience. But the build speed is a
> factor too and Cygwin g++ is at least 10 times slower than MSVC which is
> very noticeable, even on modern and fast machines.
> 
>  Anyhow, for now I'm still stuck with the libws2_32.a issue. Right now I
> really don't see any decent solution to this problem, can you think of
> anything that I'm missing?

Intercept the libtool script after it's written but before it's executed,
and use something like 'sed' to remove double slashes in paths?

'install_cygwin.bat' installs 1.5 as well as 1.7, so one option is to use
Cygwin-1.5 . Its "advantage" is that it's frozen in time, so they won't
break stuff like "C:/foo/..//bar" that they deem unimportant. Of course,
being frozen in time is also a disadvantage that's certain to grow worse
as time passes.

Then there's MSYS, which is frozen at the even-older Cygwin-1.3 kernel,
but with occasional updates to some utilities. If Charles Wilson were
immortal and we were paying him to keep this viable for us, then it might
be an excellent long-term option.

Maybe we're at a crossroads. Let's suppose, perhaps too harshly, that:

 - Cygwin has gone off in a direction that breaks "identity mounts"
     http://cygwin.com/ml/cygwin/2011-06/msg00226.html

 - the insurance industry keeps paying MS for new OS versions that
   continue to make Cygwin less reliable or harder to maintain

 - MinGW and Cygwin are committed to dw2-only exception handling, and
   this makes their tools unacceptable for GUI work on the msw platform
   (and maybe they won't fix the dll-decorations problem either)

Then our options for the long term are:

 - rely on a non-free compiler, and perhaps a ghastly command processor;
   but that would mean defecting from the free world

 - sit it out with the tools we have, and hope for MinGW and Cygwin or
   MSYS to un-break the breakage (from our POV) that's been seeping
   into their more recent releases, and for new msw versions not to
   present new obstacles

 - do it all on GNU/Linux, which seems like the best option if we're
   forced to make a radical change