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

[Vadim Zeitlin]

On Fri, 17 Jun 2011 18:01:04 +0000 Greg Chicares <address@hidden> wrote:

GC> So the information you wanted is:
GC> !!! 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../..//libws2_32.a
GC> which simplifies to:
GC>   C:/opt/lmi/MinGW-20090203/lib/libws2_32.a
GC> which is probably present in your MinGW installation as it is in mine:

 Thanks! I somehow managed to miss that the correct search directory
actually was in the path. Probably because I was absolutely certain that it
wasn't because libtool code (which I read and reread several times) didn't
find it there. But it turns out that things are even worse: the directory
is correct but there is a bug in Cygwin 1.7 ls! Indeed, the file is there:

        $ ls C:/opt/lmi/MinGW-20090203/lib/libws2_32.a
        C:/opt/lmi/MinGW-20090203/lib/libws2_32.a

and doubling the slash before it doesn't change anything, as expected:

        $ ls C:/opt/lmi/MinGW-20090203/lib//libws2_32.a
        C:/opt/lmi/MinGW-20090203/lib//libws2_32.a

But not when specifying a full path:

        $ ls 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../..//libws2_32.a
        ls: cannot access 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../..//libws2_32.a: 
No such file or directory

The double slash leads it astray, apparently, as removing it fixes the
problem:

        $ ls 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../libws2_32.a
        
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../libws2_32.a

I'm frankly speechless, you don't expect to run into bugs like this in
basic utilities like ls :-(

 AFAICS after a brief investigation, it's the fact that we have a ".."
leading to a mount point that creates the problem as I can also reproduce
it with the standard mounts even on my main machine (so it's not specific
to my VM neither):

        % ls W:/cygwin/lib/X11/../libc.a
        W:/cygwin/lib/X11/../libc.a
        % ls W:/cygwin/lib/X11/..//libc.a
        ls: cannot access W:/cygwin/lib/X11/..//libc.a: No such file or 
directory

I'll try reporting this to Cygwin folks but I have a bad feeling that they
could ignore this bug because using "mixed" paths like above is actually
not officially supported at all AFAIK.

GC> /opt/lmi/xml-scratch/libxml2-2.6.26[0]$ls -l 
/cygdrive/c/opt/lmi/MinGW-20090203/lib/libws2_32.a
GC> -rw-r--r--+ 1 Arktos None 83372 2008-12-06 02:31 
/cygdrive/c/opt/lmi/MinGW-20090203/lib/libws2_32.a
GC> 
GC> I hope that helps.

 Yes, now the problem is much more clear, thanks! Unfortunately the solution
still isn't :-(


GC> >  In the meanwhile I can't help but notice that this is yet another problem
GC> > that would have been much simpler to debug and actually probably wouldn't
GC> > have occurred at all if we didn't use this unstable mix of MinGW and
GC> > Cygwin. The fact that many paths are not understood by a half of tools 
used
GC> > surely makes the life more interesting, especially considering that it's a
GC> > different half every time... I'm just ranting, of course, as I realize 
that
GC> > there is no chance of any big changes to the build system in the near
GC> > future but anything at all, either MinGW/MSYS
GC> 
GC> Been there, done that, even got the T-shirt:
GC>   http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html
GC> The most awful shortcomings of MSYS have been alleviated since then,
GC> but it still depends on one or two volunteers, and it could slide
GC> back into un-maintained-ness any time. A burnt child dreads the fire.
GC> 
GC> > or Cygwin on its own
GC> 
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. And we'd have to distribute
GC> 'cygwin1.dll', which is okay philosophically, but creates one more
GC> task for someone to do. And the program would probably behave
GC> differently, because msvcrt and newlib are different, and both have
GC> their own problems. And it'd probably run slower than a native
GC> application.

 I don't think it would be noticeably slower as the performance-critical
parts of the code probably don't involve {any,much} system calls. But the
already slow build process would become even slower, unfortunately
anything involving the shell is horribly slow in Cygwin.

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.

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

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?

 Thanks again for testing it,
VZ