Bugzilla – Bug 317270
[OSX] set DYLD_LIBRARY_PATH
Last modified: 2007-09-15 21:24:46 UTC
---- Reported by cgaisford@novell.com 2005-02-22 22:35:34 MST ---- Call to Mono.Posix.Syscall.access results in System.DllNotFoundException: libMonoPosixHelper.dylib System.DllNotFoundException: libMonoPosixHelper.dylib in <0x000d0> (wrapper managed-to-native) Mono.Posix.Syscall:map_Mono_Posix_AccessMode (Mono.Posix.AccessMode) in <0x00024> Mono.Posix.Syscall:access (string,Mono.Posix.AccessMode) On OSX 10.3.8 running mono 1.1.4, compile and run the following application: using System; public class tester { public static void Main (string[] args) { try { Mono.Posix.Syscall.access("/tmp", Mono.Posix.AccessMode.W_OK); } catch(Exception e) { Console.WriteLine(e); } } } ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 22:52:00 MST ---- Set your DYLD_LIBRARY_PATH before launching your application to whatever $PREFIX/lib mono was installed to (/Library/Frameworks/Mono.framework/Versions/Current/lib if you're using the framework installer) -kangaroo ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 23:05:18 MST ---- I'm actually going to reopen this on myself after following up with calvin; We should change the $PREFIX/etc/mono/config target to dllmap to the _full_ path (ie; $PREFIX/lib/libMonoPosixHelper.dylib) on mac; so this will simply work "out of the box" as its a pinvoke in a default build included lib. jonp/raja? -kangaroo ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 23:16:59 MST ---- Created an attachment (id=167452) patch ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 23:17:47 MST ---- Created an attachment (id=167453) 2nd times a charm ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 23:18:22 MST ---- The attached patch will resolve this issue on OSX and can't introduce any invalid behaviour (that I can see) on other platforms -kangaroo ---- Additional Comments From grompf@sublimeintervention.com 2005-02-22 23:46:33 MST ---- Created an attachment (id=167454) dammit third time is a charm ---- Additional Comments From jonpryor@vt.edu 2005-02-23 08:14:03 MST ---- 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 possible... ---- Additional Comments From miguel@ximian.com 2005-05-10 17:45:41 MST ---- Ping. Calvin, is this still an issue with 1.1.7? ---- Additional Comments From mathieu_carpentier_2x4@yahoo.com 2005-05-14 07:39:40 MST ---- I'm running OSX 10.4 with Mono 1.1.7 and I experience the same error when using System.Windows.Forms: Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Syscall ---> System.DllNotFoundException: libMonoPosixHelper.dylib Modifying the $PREFIX/etc/mono/config file allow the application to work. I did the same tests with the tester class above. ---- Additional Comments From bmaurer@users.sf.net 2005-05-19 20:51:12 MST ---- This is an OSX packaging issue. Hardcoding the path is a bad idea, for the reasons mentioned by jonp. ---- Additional Comments From miguel@ximian.com 2005-12-02 17:53:09 MST ---- Am adding a config file for MacOS at least. But is this still an issue? Imported an attachment (id=167452) Imported an attachment (id=167453) Imported an attachment (id=167454) Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>OS X 10.3.8 running mono 1.1.4</cf_op_sys_details>