gdiplus.dll nicht gefunden, wenn MonoKickstart auf OSX verwendet

Question

Ich habe MonoKickstart verwendet, um unser Projekt - das auf OpenTK basiert - unter OSX laufen zu lassen. Ich habe das Programm vollständig zu arbeiten, aber sobald ich meinen Mono.framework entfernt (na ja, eigentlich umbenannt) die folgenden Fehler aufgetaucht:

[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) 
(...) 

Ich habe versucht, die „libgdiplus.0.dylib“ von meinem Mono Hinzufügen Installation in den enthaltenen osx-Ordner (wo auch die mono-dynamischen Bibliotheken sitzen) und den ausführbaren Ordner. Das Erstellen einer DLL-Map führt auch nichts aus, außer dass der Dateiname in der Fehlermeldung geändert wird.

Ich verwende die Ingen-Variante, so dass das Laufen in x64 nicht das Problem sein kann (siehe auch here für eine Diskussion darüber).

Answer 1

Dieser Fehler bedeutet, dass mono eine Bibliothek nicht finden konnte, die eine der Klassen benötigt, die Sie verwenden möchten.

Um die Kompatibilität mit dem .NET Framework beizubehalten, verwendet mono die gleichen Bibliotheksnamen wie Windows. Diese Namen werden mithilfe von DllMaps den Linux-Bibliotheksnamen zugeordnet.

(Substitute „.so“ mit „dylib“ für MacOS X)

Wenn eine Bibliothek Standort nicht in einem DllMap Eintrag in einer Anwendung oder einer Baugruppe CONFIG-Datei explizit angegeben wurde, wird Mono für eine Suche Bibliothek an einigen Stellen:

Das Verzeichnis, aus dem das referenzierende Bild geladen wurde. An jeder Stelle ist der dynamische Lader des Systems so konfiguriert, dass er nach gemeinsam genutzten Bibliotheken sucht. Unter Linux wird dies beispielsweise in der Umgebungsvariablen $ LD_LIBRARY_PATH und in der Datei /etc/ld.so.conf angegeben. Unter Windows wird stattdessen die Umgebungsvariable $ PATH verwendet. Der nächste Schritt zur Lösung des Problems ist das Auffinden der Datei auf Ihrem System.

$ finden/usr -name libgdiplus.so /usr/local/lib/libgdiplus.so Aha! Da ist es. Warum kann Mono das nicht finden?

Standardmäßig erstellt der Dynamic Linker grundsätzlich in allen Distributionen von Linux nur einen Cache für Dateien in/lib und/usr/lib. Da Sie Ihre Bibliothek in/usr/local/lib abgelegt haben, weiß sie nichts davon. Sie können dies mit dem folgenden Befehl überprüfen:

ldconfig -p | grep libgdiplus Der Befehl sollte keine Ausgabe produzieren, weil es nicht über die Datei weiß.

Der richtige Weg, um dieses Problem zu beheben, besteht darin,/usr/local/lib als einen der Pfade hinzuzufügen, die ldconfig indiziert. Fügen Sie dazu den Pfad zu /etc/ld.so.conf hinzu und führen Sie "ldconfig" als root aus, wodurch der Cache neu erstellt wird.

Der dynamische Linker sollte jetzt über alle Bibliotheken in diesem Pfad wissen. Sie können dies überprüfen, indem Sie den obigen Befehl eingeben erneut:

$ ldconfig -p | grep libgdiplus libgdiplus.so (libc6) => /usr/local/lib/libgdiplus.so Yay! Ihre Anwendung sollte jetzt ordnungsgemäß ausgeführt werden.

HINWEIS: Wie oben erwähnt, können Sie auch die Umgebungsvariable $ LD_LIBRARY_PATH auf den Pfad festlegen, der die Bibliothek enthält. Dies wird jedoch nicht empfohlen, da dies zu anderen Problemen führen kann und schwieriger zu warten ist.

Für weitere Informationen schauen Sie bitte auf http://www.mono-project.com/docs/advanced/pinvoke/dllnotfoundexception/