[Mono-list] effect of -nostdlib option

[Paolo Molaro]

On 03/04/03 Miguel de Icaza wrote:
> > unless something fundamental in the runtime has change recently, i don't
> > think it's so easy a fix. the problem being that you cannot reflect on a
> > corlib other than the one being used for execution. a while ago i
> > suggested adding support for Assembly.Load()ing multiple corlibs, but it
> > got turned down becuse it's too hard given the current type architecture
> > in the runtime. apparently.
> 
> It is very possible that the runtime imposes some extra constraints that
> I can not remember at this point.  The compiler can definitely be hacked
> into accepting types from a different assembly, but whether the runtimes
> (.NET and Mono) can cope with that is in fact a separate problem.

Currently the runtime doesn't allow the loading of two assemblies with
the same name: of course this limitation needs to be lifted before the
release, but I don't have the time currently to properly test it.

As for loading two different corlibs in the same mono runtime, there
are many things to consider and I'm not making any promise that will be
supported in the future (though it may work: note, the MS runtime too
crashes in some cases when you load two different corlibs in it).

Now, the point about running mcs without the mono runtime and having
it resolve types from a corlib different from the one it is currently
executing with is a little different. I assume this will be the MS
runtime: _if_ it doesn't crash when accessing some types from the
different corlib (see above) there may still be issues because the
Reflection.Emit API doesn't cope well in that scenario in some cases.
We had to add a little extension to the API in mono to be able to
compile corlib, for example (see SetCorlibTypeBuilders () in
AssemblyBuilder.cs). Since the MS runtime doesn't have that extension,
the compiled program may have references both to the corlib specified on
the command line and to the corlib mcs was run with (though I agree this
may or may not be a real issue...).

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better