Bug 317270 (MONO72877) - [OSX] set DYLD_LIBRARY_PATH
Summary: [OSX] set DYLD_LIBRARY_PATH
Status: RESOLVED FIXED
Alias: MONO72877
Product: Mono: Runtime
Classification: Mono
Component: packaging (show other bugs)
Version: 1.1
Hardware: Other Mac OS X 10.3
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-23 05:35 UTC by Calvin Gaisford
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
patch (483 bytes, patch)
2005-02-23 06:16 UTC, Thomas Wiest
Details | Diff
2nd times a charm (484 bytes, patch)
2005-02-23 06:17 UTC, Thomas Wiest
Details | Diff
dammit third time is a charm (488 bytes, patch)
2005-02-23 06:46 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:08:30 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>