[Mono-list] build of mono 1.1.7 & 1.1.8.2 fails on Solaris: failure to compile mcs

[Raja R Harinath]

Hi,

Paolo Molaro <lupus at ximian.com> writes:

> 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.

Yep.  But it makes pretty sure that the current build environment is
broken before doing that.

> Usually, this 'safe' mcs.exe won't work either (because it's too old)

That would be a bug wouldn't it :-)

If you're building from tarballs, the mcs.exe is the _not_ too old.
Anyway, mcs.exe won't be an issue -- it'll be mscorlib.dll -- and that
will match the mono source code in the tarball.  So, it is safe.

The "usually" above probably refers to your experience with SVN
checkouts rather than tarballs, and even that should be rare [1].

> 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.

That's what 'make get-monolite-latest' is there for.  Of course,
monolite-latest doesn't work on SVN checkouts of the stable branch --
but we shouldn't be changing corlib versions on the stable branch.

- Hari

[1] By default, SVN checkouts don't get any 'monolite' assemblies.
    So, the only way you can get into this situation is if

      a. You had fetched monolite into the tree at some distant time past
      b. You then managed to break the mono/mcs in your $PATH by
         installing an untested version of mono/mcs/corlib