[Mono-bugs] [Bug 72877][Nor] Changed - Call to Mono.Posix.Syscall.access results in System.DllNotFoundException: libMonoPosixHelper.dylib

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 23 Feb 2005 08:14:03 -0500 (EST)

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 jonpryor@vt.edu.


--- shadow/72877	2005-02-22 23:46:33.000000000 -0500
+++ shadow/72877.tmp.7578	2005-02-23 08:14:03.000000000 -0500
@@ -85,6 +85,34 @@
 ------- Additional Comments From grompf@sublimeintervention.com  2005-02-22 23:46 -------
 Created an attachment (id=14331)
 dammit third time is a charm
+------- Additional Comments From jonpryor@vt.edu  2005-02-23 08:14 -------
+Personally, I don't like the patch, as it's horribly horribly broken. :-)
+Baking the prefix into the config file breaks testing: it means I
+can't do "LD_LIBRARY_PATH=`pwd` mono test-app" to test a new
+libMonoPosixHelper.so; I *must* install test libs into mono's prefix,
+because that's what Mono will load.
+Baking the prefix into the config file also breaks relocatability: If
+the user wants to move the Mono framework into ~/Library/Frameworks
+from /Library/Frameworks, mono won't find libMonoPosixHelper.so. 
+(Granted, there may be other reasons that this isn't possible, but I'd
+rather not add to the problem.)
+Along the same lines, this will also break the mono-bundle installer.
+ The user can't install mono into a custom directory if the target
+directory is baked into a config file...
+Etc.  This approach is broken, and it cannot be saved.
+A better fix, if possible, would be to check at runtime for the
+directory that `mono` resides in, and automagically append the ../lib
+directory to (DY)LD_LIBRARY_PATH.  This would allow relocatable
+installs, would allow things to Just Work (even after moving) on Mac
+OS X, and would allow me to explicitly set LD_LIBRARY_PATH to test an
+un-installed libMonoPosixHelper.so.  I'm just not sure if this is