[Mono-bugs] [Bug 29749][Min] Changed - mcs /nostdlib is broken

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by martin@gnome.org.

http://bugzilla.ximian.com/show_bug.cgi?id=29749

--- shadow/29749	Thu Sep  5 18:28:25 2002
+++ shadow/29749.tmp.9613	Fri Sep  6 08:17:39 2002
@@ -1,13 +1,13 @@
 Bug#: 29749
 Product: Mono/MCS
 Version: unspecified
 OS: GNU/Linux [Other]
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: NOTABUG
 Severity: Unknown
 Priority: Minor
 Component: Misc
 AssignedTo: martin@gnome.org                            
 ReportedBy: piersh@friskit.com               
 QAContact: mono-bugs@ximian.com
@@ -36,6 +36,21 @@
 
 The other issue can be investigated, but I have not been able to
 figure out the exact problem that people are having when self-hosting
 with the makefile.s
 
 Miguel.
+
+------- Additional Comments From martin@gnome.org  2002-09-06 08:17 -------
+This is not a bug, but a feature :-)
+
+You cannot really use a different corlib in the application you're compiling that is different from the one used by the currently 
+running mcs.  This can't be "fixed" since large parts of MCS's type system rely on the fact that a fundamental type (int, long, 
+etc.) is either a TypeBuilder (when compiling corlib) or the system's type.  So the application's `int' type will always be the same 
+than typeof(int).
+
+The way it works in MCS when compiling System.dll and other parts of the class library is that the MCS which is used to compile 
+System.dll will already use the newly compiled corlib; this is done by setting the MONO_PATH.
+
+So when you compile System.dll, it'll indeed use the newly compiled corlib and not the one which is installed in the system.
+
+