All geek questions in one place

Gdiplus.dll not found when using MonoKickstart in OSX

I use MonoKickstart to get our project - which is built on OpenTK - works on OSX. I got the program to work completely, but as soon as I deleted my Mono.framework (well, actually renamed), the following error appeared:

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: gdiplus.dll at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&) at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at System.Drawing.Bitmap..ctor (System.String filename, Boolean useIcm) [0x00000] in <filename unknown>:0 at System.Drawing.Bitmap..ctor (System.String filename) [0x00000] in <filename unknown>:0 at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap:.ctor (string) (...)

I tried to add "libgdiplus.0.dylib" from my mono installation to the included osx folder (where dynamic libraries also sit) and the executable folder. Creating dllmap also does nothing but change the file name in the error message.

I use the sgen option, so running on x64 cannot be a problem (see also here for a discussion).

+6
source share
1 answer

This error means that mono could not find the library from which one of the classes you are trying to use.

To maintain compatibility with the .NET Framework, mono uses the same library names as windows. These names are mapped to linux library names using DllMaps.

(Replace ".so" with "dylib" for MacOS X)

If the library location is not explicitly specified in the DllMap entry in the application or assembly .config file, Mono will look for the library in several places:

The directory in which the link image is loaded. Anywhere, the system dynamic loader is configured to search for shared libraries. For example, on Linux, this is indicated in the environment variable $ LD_LIBRARY_PATH and the file /etc/ld.so.conf. Instead, the $ PATH environment variable is used instead. The next step in solving the problem is to find the file in your system.

$ find / usr -name libgdiplus.so /usr/local/lib/libgdiplus.so Aha! Here it is. So why can not mono find it?

By default, basically all linux distributions, the dynamic linker only creates a cache for files in / lib and / usr / lib. Since you placed your library in / usr / local / lib, it does not know about it. You can verify this using the following command:

ldconfig -p | grep libgdiplus The command should not display the result because it does not know about the file.

The correct way to fix this problem is to add / usr / local / lib as one of the paths that index ldconfig. To do this, add the path to /etc/ld.so.conf and run "ldconfig" as root, which will cause the cache to be rebuilt.

Now the dynamic linker should know about all the libraries in this path. You can verify this by typing the above command again:

$ ldconfig -p | grep libgdiplus libgdiplus.so (libc6) => /usr/local/lib/libgdiplus.so Hooray! Your application should now work correctly.

NOTE. As mentioned above, you can also set the environment variable $ LD_LIBRARY_PATH to the path containing the library, but this is not recommended because it can cause other problems and is more difficult to maintain.

For more information, see http://www.mono-project.com/docs/advanced/pinvoke/dllnotfoundexception/

+2
source

Source: https://habr.com/ru/post/983469/

More articles:


All Articles