[Mono-list] MONO_PATH or config options for System.ConsoleKeyInfo on local compile

Jonathan Pryor jonpryor at vt.edu
Fri Mar 2 06:13:40 EST 2007


On Thu, 2007-03-01 at 18:36 +0100, Holger Blasum wrote:
> on a shared host (gnu/linux 2.6.16, gcc 3.3.5) I've tried to compile
> and install locally mono-1.2.3.1 for a friend for a small 
> experimental setup via
> 
> "./configure --prefix=/home/blasum/mono 
> --enable-minimal=profiler,pinvoke,debug,reflection_emit,logging
> --disable-shared-handles --with-sigaltstack=no --with-xen_opt=no
> --with-large-heaps=no --with-ikvm-native=no --with-interp=no
> --with-preview=no"

Try using just "./configure --prefix=/home/blasum/mono".

> followed by "make -Os" (this, I think, just optimizes for space).

I think you'd need to use "make CFLAGS=-Os", otherwise `make' will
interpret -Os.

> This compiles and "make installs", but when calling a program via
> "MONO_PATH=mono/lib/mono/1.0 mono/bin/mono server" I get:
> ** (server:8670): WARNING **: The class System.ConsoleKeyInfo could
> not be loaded, used in mscorlib, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089
> Unhandled Exception: System.TypeLoadException: Could not load type
> 'System.ConsoleKeyInfo' from assembly 'mscorlib, Version=2.0.0.0,
> Culture=neutral, PublicKeyToken=b77a5c561934e089'.

System.ConsoleKey is a .NET 2.0 type (as seen by the "mscorlib,
Version=2.0.0.0" string), but the .NET 2.0 profile is only compiled with
--with-preview=yes (which is the default).  You've explicitly disabled
the .NET 2.0 profile, so it's not surprising that this fails.

Also, you shouldn't need to set MONO_PATH.  MONO_PATH is a hack,
primarily used for bootstrapping the Mono build, and should NOT be used
in normal practice.  It's not necessary.

> Thanks in advance for any suggestions or generic advice (e.g. how
> I could check whether *.cs code actually got compiled or not, which
> library files to check for, how to find out whether a library file 
> contains a certain compiled class or not, ... maybe some things
> are subtly different than I expect them to be when prejudiced by 
> previous java exposure),

Some things are *very* different from Java, in particular Java uses
CLASSPATH, while Mono should not use MONO_PATH.  Instead, you place
assemblies into the same directory as your .exe or you place them into
the GAC with gacutil (for strong-named assemblies).  The GAC permits
strongly versioning assemblies so that multiple distinct versions can be
installed and used simultaneously.

 - Jon




More information about the Mono-list mailing list