[Mono-list] Building Mono on Windows
stifu at free.fr
Wed May 26 09:33:03 EDT 2010
By the way, you might want to try to only compile the assembly that contains
the fixed bug and not the rest, then replace the concerned Mono 2.6 assembly
with the fresh SVN one. That's what I do with Windows.Forms, as I can't
compile the whole thing anymore. I just needed to tweak the WinForms project
a bit to make it compile.
It may not work every time, though, if the concerned assembly relies on
changes done elsewhere.
Giles Thomas wrote:
> Atsushi Eno wrote:
>> I have ended up to file the windows build breakage as a critical bug
>> awhile ago:
>> 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
> As an aside, perhaps it's worth me explaining what we're ultimately
> trying to do. We've got a big IronPython application , 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
> 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 ; 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
>  http://www.resolversystems.com/products/resolver-one/
>  http://firstname.lastname@example.org/msg74413.html
> Giles Thomas
> giles.thomas at resolversystems.com
> +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 - Mono-list at lists.ximian.com
View this message in context: http://mono.1490590.n4.nabble.com/Building-Mono-on-Windows-tp2228988p2231639.html
Sent from the Mono - General mailing list archive at Nabble.com.
More information about the Mono-list