Atsushi Eno wrote: > I have ended up to file the windows build breakage as a critical bug > awhile ago: > https://bugzilla.novell.com/show_bug.cgi?id=605810 > > Basically eglib migration is all of the cause of the issues. > Just disable it by autogen.sh --with-glib=system. > > And you can't actually use mono without problem. Mono built from trunk > cannot build corlib and possibly other libs. > Thanks for that. Still, it looks like it is building a DLL of some kind -- I'm getting /usr/src/mono/mcs/class/lib/basic/mscorlib.dll, size 2,608,640 bytes. Anyway, I've realised that the 2.6 branch might have all of the fixes I need, so I'll try checking that out and building it now.
As an aside, perhaps it's worth me explaining what we're ultimately trying to do. We've got a big IronPython application [1], which is currently Windows-only, but ultimately we'd like to get it running on Linux and OS X via Mono. We're trying to make sure it works on Mono for Windows as one of the first steps, for two reasons, both related to P/Invoke: 1. We've run the Mono Migration Analyzer and discovered that some of our third-party components use P/Invoke (unsurprisingly), so we're eliminating those dependencies, but because we're coding in a dynamic language we suspect that there may well be problems that the analyser has missed. Because Mono on Windows lets P/Invokes through (we've confirmed that our third-party components work on it), we're hoping that we can use it to run the application to track down problems in parallel with the work to eliminate the third-party components. 2. We have a large GUI testing framework, which also uses P/Invoke. It runs the application-under-test in-process, so if we want to test the behaviour of our application running under Mono, we need the test framework running under Mono. Again, we've confirmed that the P/Invokery it does works on Mono under Windows, so once we have the app up and running, we should be able to run our test suite under Mono; this might also help as a long-term way of letting us run regular integration tests without having to invest in a build farm full of Macs... The reason I'm trying to build Mono myself instead of using the packaged version is that the application is currently unable to run because of a bug that has been fixed on the SVN head but hasn't made its way into a release yet [2]; I also suspect that getting a big app like this running might throw up more bugs or find more unimplemented stuff, and we might wind up wanting to offer patches to the Mono codebase -- so the sooner we get going with building it ourselves, the better. Anyhow, as I said, it looks like the bug that was blocking me is in the 2.6 branch -- so I'll try building that and see if that gets me any further. Cheers, Giles [1] http://www.resolversystems.com/products/resolver-one/ [2] http://www.mail-archive.com/[email protected]/msg74413.html -- Giles Thomas [email protected] +44 (0) 20 3051 2751 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
