BUG: devel/mono doesn't look in /opt/local/lib at runtime

[chris.ridd@…]

The mono-config file included by devel/gtk-sharp maps 'libgtk-win32-2.0.0.dll' to 'libgtk-x11 -2.0.0.dylib', however an application using Gtk fails to load the dylib. This is because it appears to look for the dylib in the paths "", "/usr/local/lib", "/lib", "/usr/lib" and "." (and then across those paths in reverse order, Just In Case.)

If I set DYLD_LIBRARY_PATH to /opt/local/lib, the dylib is located correctly.

% mcs helloworld.cs -L /opt/local/lib/mono/gtk-sharp -r gtk-sharp.dll -r glib-sharp.dll
Compilation succeeded
% unsetenv DYLD_LIBRARY_PATH
% mono helloworld.exe

Unhandled Exception: System.DllNotFoundException: libgtk-win32-2.0-0.dll
in <0x000dc> (wrapper managed-to-native) Gtk.Application:gtk_init (int&,intptr&)
in <0x0004c> Gtk.Application:Init ()
in <0x0001c> Hello:Main ()

% setenv DYLD_LIBRARY_PATH /opt/local/lib
% mono helloworld.exe

(it works)

[olegb@…]

assigning to maintainer, is this still a issue ? jkh has been poking mono alot lately..

[chris.ridd@…]

Yes, this is still a problem. I just updated and rebuilt devel/mono and x11/gtk-sharp to make sure!

[chris.ridd@…]

Patch for mono/metadata/loader.c

[chris.ridd@…]

The appended diff patches (see attachment) the mono sources to avoid this problem. The patch has been been submitted up-stream.

Index: Portfile =============================================================== ==== RCS file: /Volumes/src/cvs/od/proj/darwinports/dports/devel/mono/Portfile,v retrieving revision 1.27 diff -u -r1.27 Portfile --- Portfile 4 Nov 2004 18:52:05 -0000 1.27 +++ Portfile 10 Nov 2004 21:55:27 -0000 @@ -29,6 +29,8 @@

--enable-threads=pthreads \ --mandir=${prefix}/share/man

+patchfiles patch-dyld +

destroot.destdir DESTDIR=${destroot} destroot.env DYLD_LIBRARY_PATH=${worksrcpath}/mono/mini/.libs:${worksrcpath}/mono/

interpreter/.libs:/opt/local/lib:${x11prefix}/lib

[chris.ridd@…]

A better fix is to to change the dllmap in the config file installed with a "glue" dll.

[mww@…]

does this problem still persist on version 1.1.7?

[bportmann@…]

(In reply to comment #6)

does this problem still persist on version 1.1.7?

Well yes (sometimes). I'm using 1.1.8 (darwinports) and I did not need to set DYLD_LIBRARY_PATH until I tried to use a method from Mono.Unix and then I got the error:

Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Syscall ---> System.DllNotFoundException: libMonoPosixHelper.dylib in (wrapper managed-to-native) Mono.Unix.Syscall:_L_ctermid () in <0x00090> Mono.Unix.Syscall:.cctor ()--- End of inner exception stack trace ---

which goes away if I set: export DYLD_LIBRARY_PATH=/opt/local/lib

Note that I've used lots of stuff from gtk# without needing the DYLD var set.

[schlu-do@…]

I got the same problem with the current mono version 1.1.10, when using an app called 'autopano-sift' it doesn't find the required libgdaplus (the latter one installed by DarwinPorts for mono). I worked around that by specifying the dll mapping manually in a 'System.Drawing.dll.config'.

[markd@…]

Is this still an issue with mono 1.1.12?

[markd@…]

Mono is up to 1.1.14 now. Reopen this bug if you still have a problem with the port.

[cliff.spradlin@…]

This is occuring to me in MacPorts 1.6 with Mono 1.9. Specifically, mono is not referencing libgdiplus.dylib in /opt/local/lib. /opt/local/etc/mono/config doesn't seem to contain an entry for this.

I get: System.DllNotFoundException: gdiplus.dll

[cliff.spradlin@…]

I tried adding

<dllmap dll="gdiplus.dll" target="/opt/local/lib/libgdiplus.dylib" os="!windows" />

to the mono/config file.

But then when i run the program i get: Unhandled Exception: System.EntryPointNotFoundException: GdipCreateFromContext_macosx

Am I missing something?

[andi@…]

Cc Me!

[andi@…]

Replying to cliff.spradlin@…:

I tried adding

<dllmap dll="gdiplus.dll" target="/opt/local/lib/libgdiplus.dylib" os="!windows" />

to the mono/config file.

But then when i run the program i get: Unhandled Exception: System.EntryPointNotFoundException: GdipCreateFromContext_macosx

I did the same changes and get the same result, so this problem still isn't fixed...

[nox@…]

I've fixed this problem in gtk-sharp and gtk-sharp2, I'll soon attach a patch to fix mono.

[nox@…]

Patch against mono 2.0.1 portfile

[nox@…]

Markus, could you look at the patch I've just attached to the ticket? The changes:

• Patch etc/mono/config to fix the DllImport bug.
• Fixed dependencies (mono depends on sqlite3 and cairo, see Mono.Data.Sqlite and Mono.Cairo).
• Kept icu dependency in darwin_9 platform, there is no reason to use the Apple provided icu library.

[(none)]

Milestone Port Bugs deleted

[nox@…]

See also #19929.

[tobypeterson]

This is literally the oldest open "ports" ticket we have. Just commit your fix!

[nox@…]

Which fix? The loader.c patch seems unnecessary to me as we can always write dllmaps for each dynamic library.

[alakazam@…]

Replying to cliff.spradlin@…:

This is occuring to me in MacPorts 1.6 with Mono 1.9. Specifically, mono is not referencing libgdiplus.dylib in /opt/local/lib. /opt/local/etc/mono/config doesn't seem to contain an entry for this.

I get: System.DllNotFoundException: gdiplus.dll

This is still an issue with macports 1.8 and Mono 2.4.

[Ionic (Mihai Moldovan)]

Is this still a problem for anyone?

First off, libgdiplus is still not added to the dllmap, so that's bad, but can easily be fixed.

But: even if libgdiplus is found by mono, you won't be able to use it on OS X, as the default installation of Cairo doesn't use Quartz (which is good, trust me.) libgdiplus bundles an old cairo version, but this is only used iff this bundled version is newer or at least the same version as the currently installed system cairo. As being said, it's pretty old, so this check will most likely always fail, and libgdiplus use the system cairo, with following implication: as this version doesn't have Quartz support (unlike the bundled cairo version which is getting configured with Quartz support), mono/libgdiplus won't find the function GdipCreateFromContext_macosx.

Ok, bad.

We basically have two or three options, neither which is really good, but at least both seem to work:

1.) use the system cairo and assume Quartz support is not enabled (nobody does that anyway and uses X11, I guess). In this case, we have to patch mono to use X11 drawing for WinForms instead of the Carbon functions. I haven't tested it yet, but am pretty sure it will work fine. Just rebuilding mono and testing this method in a few minutes, then reporting back.

2.) use the bundled cairo version and let gdiplus build its own Quartz enabled cairo library. We can do this by defining a bundled cairo version of like 9.9.9 to make sure libgdiplus will always use its bundled cairo library and statically link to it. Won't break your system and works, but doesn't look that good (flickering etc.).

3.) same as above, but unpack a new version of cairo which may be working much better on OS X before calling configure of gdiplus etc. Haven't tested this yet either, but will give it a shot later.

However, if nobody is interested in this (this bug is pretty old and only a few whined), I wonder whether the effort of getting it into ports is worth the benefits. Yeah, you will be able to use WinForms again with mono from MacPorts on OS X, but hum, still. Who does that, besides me currently?

[Ionic (Mihai Moldovan)]

Hm, ok, let's forget rendering to X11, mono is segfaulting for me. :/ I haven't got the time to go deep into this currently, but it may require some more work to get it working.

I'll try #3. :)

[chris@…]

Replying to ionic@…:

Is this still a problem for anyone?

I'm running into the missing GdipCreateFromContext_macosx, on OS/X 10.4 and 10.5, even a single form with a textbox and a button will crash almost immediately after launch. My symptoms are the same as is mentioned in this ticket.

On 10.4 it actually takes longer to crash, and doesn't render any elements inside the windows - though the windows are visible albeit blank ones. Using MessageBox.Show produces a blank (but seemingly correctly sized) window as well.

The steps I took were this:

• Have mono tools for visual studio installed on networked windows machine (windows 7, x64).
• Have a x86 project created and ready to debug/execute.
• Install macports for Tiger (or Leopard, depending on OS version) on networked OS/X machine.
• Run the macports selfupdate, then port install mono and gtk-sharp2
• Install the mono tools server for OS/X.
  • Note: On the 10.4 machine, I actually rebuilt mono tools server from source and all that remedied was the crashes I was encountering when doing 'Debug in mono' rather than 'Run in mono' from visual studio. Visual studio is what crashed in that case.
• Perform a 'Run in mono' from visual studio with the OS/X machine as the target for the session.

Result:

• The window appears for a split second on 10.5, and then disappears with the crash report starting off with the missing GdipCreateFromContext_macosx
• The window appears and stays open for some time on 10.4, but as soon as the window is clicked or minimized or anything the application crashes with the same error. Waiting for about 20-30 seconds will also cause it to crash, but it seems to crash faster if I try to do something with the windows that had shown up.

If there's a known fix to get past this I'd like to know what it is. This seems like a major roadblock for distributing applications intended for multiple platforms using mono; it doesn't seem as though it even works.

I am going to attempt to find alternate sources of mono, in case this is issue is specific to macports and will report here if that proves fruitful.

[chris@…]

Replying to chris@…:

Replying to ionic@…:

Is this still a problem for anyone?

I am going to attempt to find alternate sources of mono, in case this is issue is specific to macports and will report here if that proves fruitful.

This does seem related to the mono that is built using macports.

I did the following:

• port uninstall mono gtk-sharp2
• went to ​http://mono-tools.com/download/
  • downloaded the link that says "The most recent version of Mono for OS/X"
    • ​http://ftp.novell.com/pub/mono/monotools/latest/MonoFramework-x86.dmg

When I started up the mono-tools server on the mac and followed the same steps I mentioned previously from visual studio, it worked without any of the issues I encountered previously.

I hope this helps you figure out what the differences are between the novell build and the result of the macports build.

[j.bugzilla2@…]

Cc Me!

[rudloff@…]

Cc Me!

[andi@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

mono was updated to 2.10.6. Did that help anything?

[khepler]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

You shouldn't need to set DYLD_LIBRARY_PATH. The issue is that the code that is calling dlopen() isn't providing the correct path to the dylib. I'm trying to update mono to 3.1.2 since 3.x builds with clang. Maybe that will fix this.

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Note that if a DYLD variable needs to be set to work around something like this, make sure you are using DYLD_FALLBACK_LIBRARY_PATH and not DYLD_LIBRARY_PATH or you will shoot yourself in the foot

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 7d906401b31c446bf01b1835aefcd32ca33547a2/macports-ports (master):

mono: update version 3.12.1->5.18.0.240

Fixes #53320
Fixes #1936

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 7d906401b31c446bf01b1835aefcd32ca33547a2/macports-ports (master):

mono: update version 3.12.1->5.18.0.240

Fixes #53320
Fixes #1936