[Mono-bugs] [Bug 72877][Nor] Changed - Call to Mono.Posix.Syscall.access results in System.DllNotFoundException: libMonoPosixHelper.dylib
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 firstname.lastname@example.org.
--- 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 email@example.com 2005-02-22 23:46 -------
Created an attachment (id=14331)
dammit third time is a charm
+------- Additional Comments From firstname.lastname@example.org 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