I almost think that System.XML isn't compiling. This command doesn't output a dll:
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 Yet using the locally compiled mcs does output a dll: mcs /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 That's about all I've been able to figure out. Wade On Mon, 2005-10-03 at 18:07 -0600, Wade Berrier wrote: > 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
