Nagios 3.X unter Solaris 10

[vab]

1.  LD_LIBRARY_PATH sollte nie nie nie in einer Shell gesetzt sein.  Wer so was braucht, um etwas ans Laufen zu kriegen, hat etwas gundsätzlich falsch gemacht.

Also, das kommt ganz auf die Anwendung an, die man übersetzen möchte.

Leider so nicht richtig.  $LD_LIBRARY_PATH ist zur Laufzeit eines Programms wichtig, nicht zum Übersetzen.  Es bringt im Gegenteil meist den Build-Vorgang durcheinander.  Siehe dazu ld(1), ld.so.1(1), lari(1) und den "Linker and Libraries Guide".

Es gibt Anwendungen, bei denen es in den README's  ausdrücklich "gefordert" wird.

Dann sind die READMEs eben von Ahnungslosen oder Linux-Usern geschrieben worden. :-(

Zudem spricht nichts dagegen den LD-Pfad zu setzen, nur man sollte wissen was man tut.

Wissen was man tut sollte man immer.  Und wer $LD_LIBRARY_PATH in einer Shell setzt, weiß das nicht.  Das ist dasselbe Problem wie der Verweis auf crle.  Für Details bitte Onkel Google fragen.


Gruß -- Volker

[escimo]

Und wer $LD_LIBRARY_PATH in einer Shell setzt, weiß das nicht.

Na dann Volker, erweise uns die Ehre und korrigiere meine Fehlangabe, indem du Brenner und mir kurz erläuterst, wie man den Pfad für OpenSource-Anwendungen richtig setzen kann.

Ich mache das mit der Umgebungsvariable LD_LIBRARY_PATH immer - weil ich es nicht anders kenne, bin offen für Vorschläge - und hatte zu keinem Zeitpunkt je Probleme bei irgendeiner laufenden wie auch zu übersetzenden Anwendung.

Grüße
escimo

[Ebbi]

Ich denke die Betonung liegt hier auf "einer" Shell statt auf "in einer Shell".
Also eben nicht nur in einer einzigen Shell setzen, sondern ins Profil eintragen.

Bei der Oracle Installation bin ich es gewohnt es immer nur in der Shell zu setzen, von der aus ich Oracle installiere.

[escimo]

Dann lohnt der Eintrag in die "~/.profile":

Code: [Auswählen]

LD_LIBRARY_PATH=<LIBDIR-1>:<LIBDIR-2>:<u.a.>
export LD_LIBRARY_PATHSpeichern, raus und erneut das Profil einlesen mittels

  # . .profile
...

Das habe ich doch schon geschrieben. Vielleicht hat Volker das überlesen...

Grüße
Stephan

[vab]

Na, hier wird einem ja das Wort im Munde herumgedreht... :-)

Also, nochmal ganz klar formuliert:  LD_LIBRARY_PATH ist böse böse böse!
Es soll grundsätzlich nie nie nie gesetzt sein.  Nicht in irgendeiner Shell, nicht in .cshrc oder .profile oder sonstwo.

Falls es irgendwo mal eine defekte kaputte fehlerhafte problematische Software gibt, die nicht korrekt mit -R gelinkt wurde, dann findet man die für diese defekte kaputte fehlerhafte problematische Software benötigten Library-Verzeichnisse heraus und schreibt diese (und nur diese) in ein Wrapper-Shell-Script, nennt das so wie das aufzurufende Programm und benennt das Programm entsprechend um.

Beispiel:

Code: [Auswählen]

  # cat /loser/broken/bin/dummtool
  #!/bin/sh

  LD_LIBRARY_PATH=/opt/sfw/lib
  export LD_LIBRARY_PATH

  exec /loser/broken/bin/dummtool.bin "$*"
  #


Das ist der *einzige* sinnvolle Verwendungszweck.  (Na gut, und zum Shared Libraries debuggen...)

Gruß -- Volker

[escimo]

Na, hier wird einem ja das Wort im Munde herumgedreht... :-)

Also, nochmal ganz klar formuliert:  LD_LIBRARY_PATH ist böse böse böse!

Böse ist wer böses tut.

Aber wo ist denn da der Unterschied? Wenn du die Variable in einem Skript setzt, bleibt diese während der gesamten Lebensdauer der Konsolen-Session erhalten und gesetzt. Oder verstehe ich das falsch? Soll das bedeuten, dass dieses Wrapper-Skript als Sub-Shell ausgeführt wird

Tatsache, die LD_LIBRARY_PATH -Umgebungsvariable wird selten gesetzt. Beim Studio z.B. nicht:
Setting Up Access to the Developer Tools and Man Pages

[vab]

Wenn man in einem Shell-Script eine Variable definiert, gilt sie nur innerhalb dieses Scripts.  Wenn man sie mit "export" als Environment Variable deklariert, gilt dies für das aktuelle Environment und alle Kindprozesse des aktuellen Prozesses, die dieses Environment erben.

Insbesondere hat das nichts mit dem Aufrufer des Shell-Scripts zu tun.   Der kann die Variable ganz anders oder garnicht setzen, er kriegt nicht mit, wie die im Shell-Script steht.


Gruß -- Volker

[erisch]

[...]
Tatsache, die LD_LIBRARY_PATH -Umgebungsvariable wird selten gesetzt. Beim Studio z.B. nicht:
Setting Up Access to the Developer Tools and Man Pages

Ja, natuerlich nicht. Ich denke mal die waren so schlau die richtigen -R flags zu setzen.

Ich hab uebrigens auch noch nie einen LD_LIBRARY_PATH gebraucht um irgendwas zum Laufen zu kriegen, demnach stimme ich vab zu, man braucht ihn nur innerhalb von Scripts. Allerdings hat das bei mir auch ne Weile gedauert bis ich das so einigermassen raus hatte.
Probleme kriegt man wenn eigentlich nur mit fremdkompilierter Software die nicht an ihrem vorgesehenen Platz installiert oder von einem "Experten" zusammengewurstelt wurde

Mfg. Erisch

[escimo]

Probleme kriegt man wenn eigentlich nur mit fremdkompilierter Software die nicht an ihrem vorgesehenen Platz installiert oder von einem "Experten" zusammengewurstelt wurde

Dann hatte ich wohl bis jetzt immer "zusammengewurstelte Experten-Software".

Danke Euch beiden.

Grüße
escimo

[Ebbi]

Dann hatte ich wohl bis jetzt immer "zusammengewurstelte Experten-Software".

Ich auch. Und es steht "Oracle" drauf.

[erisch]

Dann hatte ich wohl bis jetzt immer "zusammengewurstelte Experten-Software".

Ich auch. Und es steht "Oracle" drauf.

Naja, ich hab von Oracle keine Ahnung. Wie installiert man das? Einfach irgendwo hinschieben und LIBRARY_PATH setzen oder wie? In diesem Falle wuerde sich halt das Script anbieten.

Aber mal anders, es ist ja nicht im Sinne des Erfinders, Bibliotheken im ganzen System zu verstreuen und nachher einfach wieder nen Eintrag zum LD_LIBRARY_PATH hinzuzufuegen.
Das waere genauso, als wenn ihr zuhause eure Buecher im ganzen Haus verteilt: Eins im Schlafzimmer, eins im Keller und eins auf dem Klo und an der Haustuer nen Zettel wo welches Buch zu finden ist

Mfg. Erisch