Opened 16 years ago

Closed 19 months ago

Last modified 19 months ago

#1936 closed defect (fixed)

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

Reported by: chris.ridd@… Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 1.0
Keywords: Cc: markd@…, nox@…, j.bugzilla2@…, rudloff@…, khepler, jeremyhu (Jeremy Huddleston Sequoia)
Port: mono

Description (last modified by ryandesign (Ryan Schmidt))

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)

Attachments (2)

patch-dyld (767 bytes) - added by chris.ridd@… 16 years ago.
Patch for mono/metadata/loader.c
mono-2.0.1_1.diff (3.8 KB) - added by nox@… 12 years ago.
Patch against mono 2.0.1 portfile

Download all attachments as: .zip

Change History (42)

comment:1 Changed 16 years ago by olegb@…

Owner: changed from darwinports-bugs@… to jkh@…

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

comment:2 Changed 16 years ago by chris.ridd@…

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

Changed 16 years ago by chris.ridd@…

Attachment: patch-dyld added

Patch for mono/metadata/loader.c

comment:3 Changed 16 years ago by 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
Last edited 4 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:4 Changed 16 years ago by chris.ridd@…

Cc: mww@… added
Owner: changed from jkh@… to mww@…

comment:5 Changed 16 years ago by chris.ridd@…

attachments.isobsolete: 01

comment:6 Changed 16 years ago by chris.ridd@…

op_sys: All
rep_platform: All

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

comment:7 Changed 15 years ago by mww@…

does this problem still persist on version 1.1.7?

comment:8 Changed 15 years ago by 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.

comment:9 Changed 15 years ago by 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'.

comment:10 Changed 15 years ago by markd@…

Cc: markd@… added

Is this still an issue with mono 1.1.12?

comment:11 Changed 14 years ago by markd@…

Resolution: fixed
Status: newclosed

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

comment:12 Changed 12 years ago by cliff.spradlin@…

Resolution: fixed
Status: closedreopened

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

comment:13 Changed 12 years ago by 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?

comment:14 Changed 12 years ago by jmroot (Joshua Root)

Cc: mww@… removed
Milestone: Port Bugs

comment:15 Changed 12 years ago by andi@…

Cc: andi@… added

Cc Me!

comment:16 in reply to:  13 Changed 12 years ago by 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...

comment:17 Changed 12 years ago by nox@…

Cc: nox@… added
Description: modified (diff)

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

Changed 12 years ago by nox@…

Attachment: mono-2.0.1_1.diff added

Patch against mono 2.0.1 portfile

comment:18 Changed 12 years ago by 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.

comment:19 Changed 12 years ago by ryandesign (Ryan Schmidt)

Description: modified (diff)
Port: mono added

comment:20 Changed 11 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

comment:21 Changed 11 years ago by nox@…

See also #19929.

comment:22 Changed 11 years ago by tobypeterson

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

comment:23 Changed 11 years ago by nox@…

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

comment:24 in reply to:  12 Changed 11 years ago by 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.

comment:25 Changed 10 years ago by 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?

comment:26 Changed 10 years ago by 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. :)

comment:27 in reply to:  25 ; Changed 10 years ago by 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.

comment:28 in reply to:  27 Changed 10 years ago by 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:

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.

comment:29 Changed 9 years ago by j.bugzilla2@…

Cc: j.bugzilla2@… added

Cc Me!

comment:30 Changed 9 years ago by rudloff@…

Cc: rudloff@… added

Cc Me!

comment:31 Changed 9 years ago by mww@…

Owner: changed from mww@… to macports-tickets@…
Status: reopenednew

comment:32 Changed 9 years ago by andi@…

Cc: andi@… removed

Cc Me!

comment:33 Changed 9 years ago by ryandesign (Ryan Schmidt)

mono was updated to 2.10.6. Did that help anything?

comment:40 Changed 7 years ago by khepler

Cc: khepler@… added

Cc Me!

comment:41 Changed 7 years ago by 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.

comment:42 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added

Cc Me!

comment:43 Changed 7 years ago by 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

comment:44 Changed 19 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Owner: changed from macports-tickets@… to MarcusCalhoun-Lopez
Status: newaccepted

comment:45 Changed 19 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: acceptedclosed

In 7d906401b31c446bf01b1835aefcd32ca33547a2/macports-ports (master):

mono: update version 3.12.1->5.18.0.240

Fixes #53320
Fixes #1936

comment:46 Changed 19 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

In 7d906401b31c446bf01b1835aefcd32ca33547a2/macports-ports (master):

mono: update version 3.12.1->5.18.0.240

Fixes #53320
Fixes #1936

Note: See TracTickets for help on using tickets.