[Mono-dev] Use of mono-sgen causes mono path detection fallback

[Chris Ball]

I maintain a Linux build of mono (and F#) that is hosted via NFS, and used
on a large number of machines, but the mount directory is not always
identical. I have discovered that the mono-sgen binary does not properly
detect the location of mscorlib on my systems, but the normal mono binary
has no problems. This problem occurs in both 2.10.9 and 3.0.4. My "simple"
test case (for mono 3.0) is to build the runtime, rename the output
directory, and run the following:
   MONO_GAC_PREFIX=/tmp/mono-test/renamed \
  PATH=$PATH:/tmp/mono-test/renamed/bin \
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/mono-test/renamed/lib \
  /tmp/mono-test/renamed/bin/mono /tmp/mono-test/renamed/lib/mono/4.5/sn.exe
   MONO_GAC_PREFIX=/tmp/mono-test/renamed \
  PATH=$PATH:/tmp/mono-test/renamed/bin \
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/mono-test/renamed/lib \
  /tmp/mono-test/renamed/bin/mono-sgen
/tmp/mono-test/renamed/lib/mono/4.5/sn.exe
The first command succeeds (prints out the usage). The second command
fails, returning:
   The assembly mscorlib.dll was not found or could not be loaded.
  It should have been installed in the
`/source/on/build/server/lib/mono/4.5/mscorlib.dll' directory.
I have traced the issue to mono/metadata/assembly.c:compute_base:
   /* Not a well known Mono executable, we are embedded, cant guess the
base */
  if (strcmp (p, "/mono") && strcmp (p, "/monodis") && strcmp (p, "/mint")
&& strcmp (p, "/monodiet"))
    return NULL;

By changing this as follows, the behavior is corrected:
   /* Not a well known Mono executable, we are embedded, cant guess the
base */
  if (strcmp (p, "/mono") && strcmp (p, "/mono-sgen") && strcmp (p,
"/monodis") && strcmp (p, "/mint") && strcmp (p, "/monodiet"))
    return NULL;
I have not filed this as a bug or submitted a patch yet, because I am not
sure if other binaries should be included in this test as well (e.g.
pedump). My preliminary tests using "pedump --verify all" suggest that it
should also be added to the "well known" list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130304/0ce4860d/attachment.html>