[Mono-dev] Mono 1.0 and 2.0 profiles
monoman at gmail.com
Wed Apr 8 15:18:00 EDT 2009
AFAIR, AOTed code still need the original assemblies can then be compressed
separately as data, or those numbers doesn't include that part. It would be
even better if the runtime could use those zipped versions directly instead
of having them unzipped on install. It would be similar to how java jars
Just my two cents,
On Wed, Apr 8, 2009 at 3:13 PM, Miguel de Icaza <miguel at novell.com> wrote:
> Sorry, I forgot to CC m-d-l in the last post.
> > Hello Mantas,
> > Thanks for your feedback:
> > > So adding of reference to .NET Socket API adds two new dependencies
> > > System.dll and System.Xml.dll and ends up with 2.1 MB of additional
> > > ARM code.
> > Would you mind checking why Sockets is pulling System.Xml for you?
> > Another thing that would be useful is to find out why System ends up
> > so large even with the linker being used if you are only using sockets.
> > For example, let us consider the Silverlight profile: it requires us
> > to ifdef some steps during the build time that to assist the linker.
> > The linker works, but it can not do magic without some help here and
> > there.
> > That is why I am wondering if we can do something along the lines of
> > adding a build profile that would work for embedded case scenarios,
> > but still based on a generics-based profile instead of the non-
> > generics build.
> > I am interested in getting to the bottom of why the generics-based
> > profile can not be used in embedded systems and address that issue,
> > because that is where most of the pain comes from (other pieces are
> > just low-tech variations of what the Mono linker can do).
> > If we can figure out a way to have you guys up and running with a
> > generics-based mscorlib that consumes as much memory/space as the 1.0
> > profile I think we will all win.
> > Question: what are the problems that you guys are facing with AOT and
> > generics?
> > > Miguel, I saw your comment that people who are using profile 1.0
> > > should stick with mono-2-4 then I would like to ask what about AOT
> > > on other platforms support? Let's say mono adds PPC AOT support to
> > > mono-2-6 will it be backported to mono-2-4? If not then I see the
> > > problem how mono based applications could be developed for small
> > > devices that currently are not supported by mono-2-4, but maybe will
> > > be supported in the next versions.
> > Possibly, but I have a hard time coming up with a PowerPC device that
> > can be considered "a small device".
> > The only case I am aware of where the AOT code for PPC makes sense are
> > gaming consoles, and those are capable systems.
> > Miguel.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
Rafael "Monoman" Teixeira
"To be creative means to be in love with life. You can be creative only if
you love life enough that you want to enhance its beauty, you want to bring
a little more music to it, a little more poetry to it, a little more dance
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list