Nagios-/Icinga-Portal

wie wurde icinga installiert? source/pkg? auf welchem os? wusste configure von /usr/local/lib ?

grep mal aus dem configure raus, ob es libltdl findet. auf solaris/*bsd tuts das normalerweise nicht und man muss den pfad dazu via lib dir nachfuettern.

Man muss im Startscript oder einen anderen Stelle den LD_LIBRARY_PATH entsprechend ergänzen.

Ähnliches gilt z.B. auch für die Oracle Umgebungsvariablen
Ich packe alle extra Variablen für Icinga in eine Datei z.B. icinga_profile und schreibe dann ins startscript

: vieleicht solte man so eine Nachlademöglichkeit für Umgebungsvariablen z.B in /etc/sysconfig in Linux in die nächste Version einbauen

Zitat von »Tommi«

Man muss im Startscript oder einen anderen Stelle den LD_LIBRARY_PATH entsprechend ergänzen.

	Quellcode
1 2	LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export LD_LIBRARY_PATH

man kann auch im forum suchen, denn das problem gabs eben auf freebsd schonmal.

https://nagios-portal.org/wbb/index.p…&highlight=ltdl <- erster hit. es ist zwar nicht unbedingt dasselbe, bezieht sich aber auf denselben fehler. https://nagios-portal.org/wbb/index.p…ltdl#post142455
das problem mit den libs umgeht man ja nur, wenn der linker nicht weiss wo die ltdl.h liegt und dann die falsche ltdl.h mit reinbaut.

Zitat von »Tommi«

Ähnliches gilt z.B. auch für die Oracle Umgebungsvariablen
Ich packe alle extra Variablen für Icinga in eine Datei z.B. icinga_profile und schreibe dann ins startscript

	Quellcode
1 2 3 4	ICINGAVARS=/opt/icinga/etc/icinga_profile if [ -r $ICINGAVARS ]; then . $ICINGAVARS fi

: vieleicht solte man so eine Nachlademöglichkeit für Umgebungsvariablen z.B in /etc/sysconfig in Linux in die nächste Version einbauen

solltest du wohl dein init script mal updaten? *ggg*

https://dev.icinga.org/issues/1015

Zitat von »dnsmichi«

https://dev.icinga.org/issues/1015

Ah, noch gar nicht gesehen. Meine Scripte sind noch von 1.2, die hatte ich soviel geändert, das ich die aus den neuen Versionen nicht mehr aktualisiert habe.

Zitat

das problem mit den libs umgeht man ja nur, wenn der linker nicht weiss wo die ltdl.h liegt und dann die falsche ltdl.h mit reinbaut.

(korrinten-modus on :-))): die .h sind die Includes, da steht aber nichts von der Position drin. Es geht um die Pfade zu den shared *.so libs, aber auch da kann man rpath (Position der Libs zur Linkzeit) ausschalten bzw. macht den den Build auf einer anderen maschine und hat auf dem Prod-System die libs ganz wo anders. Dann braucht man wieder LD_LIBRARY_PATH bzw.SHLIBPATH(HPUX) bzw einen Eintrag in ld.conf. Richtig ist natürlich das die Version der lib zum .h beim kompilieren passen muss. (ganz beliebtes Spiel bei Solaris mit den System-libs und gleichnamigen Gnu Versionen wie libiconv)

Zitat von »Tommi«

(korrinten-modus on :-)))

Korinthen

Zitat von »Tommi«

(korrinten-modus on :-))): die .h sind die Includes, da steht aber nichts von der Position drin. Es geht um die Pfade zu den shared *.so libs, aber auch da kann man rpath (Position der Libs zur Linkzeit) ausschalten bzw. macht den den Build auf einer anderen maschine und hat auf dem Prod-System die libs ganz wo anders. Dann braucht man wieder LD_LIBRARY_PATH bzw.SHLIBPATH(HPUX) bzw einen Eintrag in ld.conf. Richtig ist natürlich das die Version der lib zum .h beim kompilieren passen muss. (ganz beliebtes Spiel bei Solaris mit den System-libs und gleichnamigen Gnu Versionen wie libiconv)

prinzipiell ja, die location spreche ich dir gar nicht ab. nur wenn der core eine libltdl laden will, muss er auch wissen, was er davon braucht. also im normalfall wird diese lib irgendwelche symbole exportieren (funktionen, usw, guck mit 'nm' nach). allerdings musst du diese funktionen auch irgendwo bei dir im code verwenden (zb nebmods.c und dlopen). wenn du jetzt keine ltdl.h dort herumliegen hast, wo der linker herumsucht, damit du den code korrekt kompilieren kannst, wird er dich anspeiben. um dem linker die hilfe abzunehmen, fackelt man das via configure ab. wenns ned matched, hast du ein problem.
bestes beispiel - rhel 5.x und pcre. das hat keinen unicode support in der uraltfassung von 2006, ist aber so tief im system verankert, sodass mans mit bedacht angreifen muss. wenn du dir eine neue lib version baust, bleibt zu hoffen, dass all jene libs die gegen die alte pcre.h linken, eh noch funktionieren, waehrend die neu gebauten auch die neue pcre.h verwenden. bloed an der sache ist nur, dass php auch kompiliert wurde - gegen die uralt fassung. also muesste man das genauso angreifen - entweder src package rebuil reinstall, selbst gebaut, oder externe quellen. genau das ist das problem, was wir seit anbeginn mit icinga-web und agavi haben, ausfuehrlich erlaeutert hier: https://dev.icinga.org/issues/466

und binaries (wenn auch in packages) auf systeme zu kopieren/installieren, wo die pfade dann erst recht wieder unterschiedlich sind, widersprechen imho einem build respektive package. da wuerden dich einige packager erschlagen, wenn du ihnen sagst, dass ihre packages multi-kulti eines fuer alles sein sollten ;-)