Wo finden C#-Programme, die auf einem Lenovo Thinkstation-Desktop mit Ubuntu Linux 16.04 laufen und Quellcode verwenden, bei dem die gemeinsam genutzten Objekte (so's) von DLLImport zur Laufzeit nach gemeinsam genutzten Objekten suchen? Auch wenn sich das gemeinsam genutzte Objekt libxyz.so im selben Unterverzeichnis wie das Unterverzeichnis der C#-Programmdatei befindet, habe ich festgestellt, dass es notwendig ist, LD_LIBRARY_PATH zu exportieren, um ein korrektes Verhalten der C#-Programmdatei sicherzustellen. Warum ist das so?
Wir haben festgestellt, dass bei der Installation vieler Linux-Softwareprodukte von Drittanbietern die Installationsprogramme oder -skripte libc.so.6 im Unterverzeichnis /usr/libx86_64-linux-gnu finden, ohne dass der Kunde einen LD_LIBRARY_PATH angeben muss, der dieses Unterverzeichnis enthält. Warum ist das so?
Und wenn wir die C#-ausführbare Datei als Point-and-Click-Monodienst ausführen möchten, wie geben wir LD_LIBRARY_PATH global an, bis der Computer neu gestartet wird, ohne ein Ubuntu Linux 16.04-Terminal öffnen zu müssen? Gibt es eine elegantere Möglichkeit, als LD_LIBRARY_PATH als Envp-Argument an execle zu übergeben?
Antwort1
Ich werde versuchen, alle drei Teile dieser Frage für Sie zu beantworten
[Warum ist es] notwendig, LD_LIBRARY_PATH zu exportieren, um ein korrektes Verhalten ausführbarer C#-Programme sicherzustellen
Installationsprogramme oder Skripte finden libc.so.6 im Unterverzeichnis /usr/libx86_64-linux-gnu, ohne dass der Kunde einen LD_LIBRARY_PATH angeben muss.
Auf verknüpfte Bibliotheken wird von einer bekannten Gruppe von Standorten aus verwiesen. Normalerweise handelt es sich dabei um Systemverzeichnisse, damit sie von privilegiertem Code sicher verwendet werden können (sie können nicht von Benutzern überschrieben werden).
Wenn Sie dies verstehen, erkennen Sie, dass die Menge der bekannten Standorte nicht enthalten kann .. Sie können die Menge der bekannten Standorte sehen, indem Sie die Textdatei untersuchen /etc/ld.so.conf. Wenn Sie sie bearbeiten, müssen Sie ausführen, ldconfigum die entsprechende Binärdatenbank zu aktualisieren.
Die Menge der bekannten Standorte kann pro Anwendung erweitert werden, indem eine Instanz von verwendet wird , die eine durch Doppelpunkte getrennte Liste der zu durchsuchenden Verzeichnisse annimmt. Wenn Sie dies jedoch verwenden, verwirft der Kernel alle Berechtigungen eines Programms - Sie können es also nicht verwenden , um beispielsweise LD_LIBRARY_PATHzu betrügen passwdoder zu verwenden.sudo
wie geben wir LD_LIBRARY_PATH global an, bis der Computer neu startet [...] Gibt es eine elegantere Möglichkeit, als LD_LIBRARY_PATH als Umgebungsargument an execle zu übergeben?
Es global festzulegen wäre eine wirklich schlechte Idee, da es , und andere privilegierte Programme beschädigen würde sudo. passwdIch sehe LD_LIBRARY_PATHjedoch nicht, warum Sie es nicht in einem Shell-Skript pro Anwendung festlegen können. Sie müssen es nicht als „Terminalprogramm“ starten, da es nichts Bedeutendes in ein Terminal schreibt
#!/bin/bash
#
APP_DIR=/path/to/application
APP_DIR_LIB="$APP_DIR/lib"
APP_DIR_EXE="$APP_DIR/someprogram.exe"
export LD_LIBRARY_PATH="$APP_LIB_DIR"${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
exec "$APP_DIR_EXE" "$@"
echo "Ooops" >&2
exit 1
Ich habe "$@"es so verwendet, dass alle an das Skript übergebenen Argumente auf die ausführbare Datei selbst angewendet werden.
Ich weiß nicht, wie Sie einen Monodienst starten oder stoppen würden, daher kann ich Ihnen diesbezüglich nicht weiterhelfen. Wenn Sie Ihre Frage aktualisieren, werde ich sehen, ob ich hier etwas hinzufügen kann.