On 07/20/05 Miguel de Icaza wrote: > > 1. cmp shows no difference between class/lib/monolite/mcs.exe (part of the > > distribution) and the newly made class/lib/basic/mcs.exe (what is supposed > > to be the newly made mcs.exe) (The path references are relative to the mcs > > subdirectory.) > > This is strange, since the executables encode a GUID which should be > different on every build.
I think part of the build system will copy from monolite/mcs.exe to basic/mcs.exe or something like that if it thinks the current mcs doesn't work. Usually, this 'safe' mcs.exe won't work either (because it's too old) and at this point it's hard to figure out how to get the build going again, because almost always you'll find the mcs.exe overwritten by this automatic mechanism. At least that is what I recollect when a build failed and I had to search from where my newly installed clean mcs.exe was overwritten. Maybe hari can explain more. > > 2. file class/lib/basic/mcs.exe indicates: data. Even for an incorrectly > > built binary object file indicates something like: "_binary_name_: ELF > > 32-bit MSB executable SPARC Version 1, dynamically linked, stripped" on a > > sparc system. > > Maybe you are comparing to /usr/ccs/bin/mcs which is a Solaris command? > > Or somehow the build system got that binary? A decent file(1) should report mcs.exe as a PE binary, but knowing this is Solaris... lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
