[Fwd: Re: [Mono-dev] Mono 1.1.9.1 Windows Installer Released]

Wade Berrier wberrier at novell.com
Mon Oct 3 20:07:52 EDT 2005 

One more note, looks like monodis.exe, mono.exe, and monograph.exe were
not statically linked.

On Mon, 2005-10-03 at 18:05 -0600, Wade Berrier wrote:
> Hey,
> 
> A little while ago I discovered a dumb mistake on my part:  I didn't 
> have libtool installed.
> 
> It's installed now and here's my cygwin versions:
> 
> $ libtool --version
> ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15)
> 
> $ automake --version
> automake (GNU automake) 1.9.6
> 
> Also, I'm building from the mono 1.1.9.1 tarball, not from the tag or
> trunk:
> 
> http://go-mono.com/sources/mono-1.1/mono-1.1.9.1.tar.gz
> 
> So, now when I build, the .dll files are generated, but now the build
> fails with the same error I got when building under Paco's cygwin
> environment of Mar 2004:
> 
> MONO_PATH="../../class/lib/basic;
> $MONO_PATH" /tmp/scratch/mono-1.1.9.1/runtime/mono-wrapper  ../../class/lib/basic/mcs.exe  /nologo /optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB /debug+ /debug:full /noconfig -r:mscorlib.dll -r:System.dll -nowarn:0162 -nowarn:0618 -nowarn:0612 -target:library -out:System.Xml.dll `echo System.Xml.XPath/Parser.cs Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs | tr '/' '\\\\'` @../../build/deps/basic_System.Xml.dll.response
> make[8]: Leaving directory
> `/tmp/scratch/mono-1.1.9.1/mcs/class/System.XML'
> make[7]: Leaving directory
> `/tmp/scratch/mono-1.1.9.1/mcs/class/System.XML'
> make[6]: Leaving directory `/tmp/scratch/mono-1.1.9.1/mcs/class'
> make[5]: Leaving directory `/tmp/scratch/mono-1.1.9.1/mcs'
> make[8]: *** [../../class/lib/basic/System.Xml.dll] Error 255
> make[7]: *** [do-all] Error 2
> make[6]: *** [all-recursive] Error 1
> make[5]: *** [all-recursive] Error 1
> make[4]: *** [profile-do--basic--all] Error 2
> make[3]: *** [profiles-do--all] Error 2
> make[4]: Leaving directory `/tmp/scratch/mono-1.1.9.1/mcs'
> make[3]: Leaving directory `/tmp/scratch/mono-1.1.9.1/mcs'
> make[2]: Leaving directory `/tmp/scratch/mono-1.1.9.1/runtime'
> make[1]: Leaving directory `/tmp/scratch/mono-1.1.9.1'
> /tmp/scratch/mono-1.1.9.1/libtool: line
> 6594: /tmp/scratch/mono-1.1.9.1/mono/handles/semdel: No such file or
> directory
> /tmp/scratch/mono-1.1.9.1/libtool: line 6594:
> exec: /tmp/scratch/mono-1.1.9.1/mono/handles/semdel: cannot execute: No
> such file or directory
> make[2]: *** [all-local] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> Then I go into mono/handles where semdel.c is and when I run make, I get
> a slew of errors.  Looks like some clash with the win32 api...?  I'll
> attach the log.  I'll also CC Dick because is looks like he does a lot
> with semdel.
> 
> Getting closer.
> 
> Wade
> 
> 
> On Tue, 2005-10-04 at 00:00 +0200, Zoltan Varga wrote:
> >                                               Hi,
> > 
> >   mono builds fine using the latest cygwin libs for me. Altought, it
> > is still statically linked
> > even if I tell disable it, so its not all good. What version of
> > automake and libtool are you using, ie what does automake --version
> > and libtool --version return ?
> > 
> >                      Zoltan
> > 
> > On 10/3/05, Wade Berrier <wberrier at novell.com> wrote:
> > > Here's another error which makes me think something is wrong besides my
> > > environment or the libraries I have.
> > >
> > > *** Warning: linker path does not have real file for library -lole32.
> > > *** I have the capability to make that library automatically link in
> > > when
> > > *** you link to this library.  But I can only do this if you have a
> > > *** shared version of the library, which you do not appear to have
> > > *** because I did check the linker path looking for a file starting
> > > *** with libole32 and none of the candidates passed a file format test
> > > *** using a file magic. Last file checked: /lib/w32api/libole32.a
> > > *** The inter-library dependencies that have been dropped here will be
> > > *** automatically added whenever a program is linked with this library
> > > *** or is declared to -dlopen it.
> > >
> > > That's a file provided by cygwin in the w32api package.  I'm trying to
> > > keep my cygwin installation to a minimum:
> > >
> > > autoconf
> > > automake
> > > bison
> > > cpio
> > > gcc-mingw-core
> > > gcc-mingw-g++
> > > make
> > >
> > > openssh
> > > unzip
> > > zip
> > > wget
> > >
> > > cvs
> > > cygrunsrv
> > > patch
> > > subversion
> > > vim
> > > wget
> > >
> > > And of course other packages get selected by dependency.
> > >
> > > Am I missing something obvious?
> > >
> > > Wade
> > >
> > >
> > > On Mon, 2005-10-03 at 13:19 -0600, Wade Berrier wrote:
> > > > Hey,
> > > >
> > > > On Sat, 2005-10-01 at 02:23 +0200, Zoltan Varga wrote:
> > > >
> > > > > This works fine on my system using latest cygwin. My libint is in
> > > > > /lib/libintl.a. Perhaps you don't have that package installed, or
> > > > > libintl-1.dll is in a directory
> > > > > in your PATH so libtool finds it first ?
> > > >
> > > > This same error happens with a lot of deps when I link (gmodule-2.0,
> > > > gthread-2.0, glib-2.0, intl, iconv, ws2_32, psapi,
> > > > ole32).
> > > >
> > > > I do have libintl-1.dll in my path.  What should my environment be?
> > > >
> > > > Are you using the cygwin glib deps?  I'm using the following glib deps:
> > > >
> > > > ftp://ftp.gtk.org/pub/gtk/v2.6/win32/glib-2.6.6.zip
> > > > ftp://ftp.gtk.org/pub/gtk/v2.6/win32/glib-dev-2.6.6.zip
> > > > http://www.gimp.org/~tml/gimp/win32/pkgconfig-0.15.zip
> > > > http://www.gimp.org/~tml/gimp/win32/libiconv-1.9.1.bin.woe32.zip
> > > > http://www.gimp.org/~tml/gimp/win32/gettext-0.14.5.zip
> > > >
> > > > I'm using these so that I can build with them and also package them up
> > > > for the installer.
> > > >
> > > > I guess the only other place I know about that I could get the deps is
> > > > from gladewin32.  He doesn't offer zip files (which is easier to
> > > > automate with) but if I had to, I could create a zip file from what his
> > > > installer lays down.
> > > >
> > > > I don't think that using the gladewin32 fixes the problem though.  I
> > > > still get the same errors when I build against the 1.1.8.3 mono
> > > > installer, and 1.1.8.3 came with the gladewin32 files.
> > > >
> > > > Ideas?
> > > >
> > > > Wade
> > >
> > >
> >

More information about the Mono-devel-list mailing list