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

[Greg Chicares]

On 2011-06-18 14:18Z, Vadim Zeitlin wrote:
> 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.

That's fine with me. I'm grumbling only about the way thunderbird behaves; but
I've learned to work around it. Let me know if you'd like to receive replies
personally as well as on the list--that'd be speedier and no harder for me.

> 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.

Good to hear. That's Charles Wilson's package: the mingw.org toolchain
presented as a cross-compiler for Cygwin. There's supposed to be a 4.6.x
release from mingw.org soon, and I'm sure Charles will update this package
when that's released. AIUI, the DLL-decorations problem was fixed in 4.6 .

> 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.

I believe they could be more careful about the provenance of their w32api
headers, but that's the only misgiving I have about their project--and I
suppose we could always fall back on the w32api headers that mingw.org
and cygwin.com use if this becomes a problem for us.

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

I do agree that MinGW-w64 has greater vitality than mingw.org, so it
might indeed be a better choice for us. Furthermore...

> 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?

Here's a more detailed discussion:

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

Is that case actually so rare with wxWidgets that it really can't occur
in lmi? If we can't be highly confident of that, then we have a compelling
reason to prefer sjlj.

> I'll test with it instead of i686-pc-mingw32-g++ unless you see any reason
> to prefer the latter.

Depends on the answer to the dw2-versus-sjlj and Zope-license questions.

> 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.

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

>  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.

I'm hoping we'll find that mingw-w64.sourceforge.net already does this.

> 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

Correct: they don't seek to break that technique. But if it gets broken
as a side effect of some change that otherwise seems desirable, then
they're unlikely to put a lot of effort into any workaround.

> 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.

My biggest concern is preserving our ability to choose a gcc version that's
not necessarily recent enough to be offered by the Cygwin installer. The
above discussion suggests there's reason to hope that the MinGW-w64 people
have solved that issue directly. Aside from that, I have no reason to prefer
identity mounts to a clean alternative.