[trunk r4394] Reintegration of test-branch, Libcrypto Problem gelöst

[sven@mainz]

Hab jetzt alles leer gemacht und den Trunk noch mal ausgecheckt, funzt problemlos. Einfach top!

 

[colonia27]

Gut, daß du mich dran erinnerst Sven..... Feedback ganz vergessen.....
Hier ebenfalls alles bestens in rev. 4432 und Hermanns freetzmount.
Mein Wunschimage steht soweit demnach erstmal, zumindest bis mich wieder der Test-Wahn überkommt :-D
Signatur pass ich morgen mal an.

 

[SaschaBr]

Dann gebe ich auch mal Feedback:
Habe vorhin ein neues Image gebaut.
Ich habe beisher keine Probleme, und dank dem Patch im Trac von ER13 sind meine Fehler des Samba beim starten auch verschwunden.

 

[cuma]

Ich finde die neuen Option für Samab aber nicht unbedingt so toll. Es werden wahrscheinlich viele Probleme bekommen, wenn die ehemaligen Kommentare nun Parameter sind.

 

[SaschaBr]

Das sehe ich genau so, denke aber auch, dass das nur eine Übergangsphase ist.
Vieleicht sollte man anstatt einer Texterea Optionsfelder dafür verwenden (ähnlich wie im AVM-Firewall-cgi).

 

[Silent-Tears]

Das hat aber mal so gar nichts mit dem Thema dieses Threads zu tun. Bitte lagert den Kram ins entsprechende Ticket oder in einen Thread dahingehend.

 

[cuma]

Oh, stimmt. Vielleicht könnte jemand das "Samba" in einen neuen Thread auslagern?

genau.....

 

[PsychoMantis]

Ich habe hier folgendes Problem, nach dem ich "7270_v3_04.80freetz-devel-4428M.de_20100305-123826.image" gebaut ("svn co http://svn.freetz.org/trunk freetz") habe:

/var/mod/root # asterisk
asterisk: can't load library 'libncurses.so.5'
/var/mod/root # find / -name libncurses.*
/usr/lib/freetz/libncurses.so
/usr/lib/freetz/libncurses.so.5
/usr/lib/freetz/libncurses.so.5.7
/var/mod/root # ldd /usr/sbin/asterisk
        libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x2aabe000)
        libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x2aafc000)
        libdl.so.0 => /lib/libdl.so.0 (0x2abf0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2ac03000)
        libncurses.so.5 => not found
        libm.so.0 => /lib/libm.so.0 (0x2ac27000)
        libresolv.so.0 => /lib/libresolv.so.0 (0x2ac51000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ac63000)
        libc.so.0 => /lib/libc.so.0 (0x2ac81000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
/var/mod/root #

Das war paar subversionen vorher nicht so. Wollte das nur mal so melden, da ich es als ein Fehler ansehe.

 

[Silent-Tears]

Wahrscheinlich ist entweder dein PAtch oder asterisk an sich noch nicht an diese gegebenheiten angepasst. Passiert eben dies mit einem _unmodifizierten_ trunk?

 

[PsychoMantis]

Natürlich ist der Patch nicht angepasst. Er ist (fast) so wie er schon vor einem Monat war. Woher soll also Asterisk wissen, dass die libs jetzt wo anders liegen? Wie sage ich ihm das? Wie pass ich den patch an?
Ich kann das Problem ja lösen, wenn ich mini_fo installieren und dann in /lib einen symlink rein tue, aber ich habe keine Ahnung welche Nachteile/Risiken mini_fo hat.

 

[Silent-Tears]

Schau mal nach, wie wir die anderen Pakete mit den Library-Pfaden angepasst werden, da gibt es sicherlich einen Anhaltspunkt für dich und dein Makefile.

 

[matze1985]

Schau dir mal die Änderungen des Changesets an, da es sehr viel recht unübersichtlich vielleicht, aber im Makefile.in sieht man die neu verwendetetn submake-Makros.

Dort wird unter anderem LD_RUN_PATH="/usr/lib/freetz" für die make-env gesetzt, wenn ich mich nicht verlesen habe, sorgt das dafür, dass ldd nicht in den Standart-Lib-Ordnern (/usr/lib und /lib) sucht sondern als Standart in eben dem /usr/lib/freetz


Hoffe das ist soweit richtig, wenn nicht korrigiert mich jemand...

 

[sf3978]

@PsychoMantis
Versuch mal Folgendes:

In der asterisk.mk-Datei alle "$(MAKE) -C $(ASTERISK_DIR)" in "$(SUBMAKE) -C $(ASTERISK_DIR)" ändern. Alle "PATH="$(TARGET_PATH)" löschen.
Auch "-$(MAKE) -C $(ASTERISK_DIR) $(ASTERISK_MAKE_PARAMS) clean" in "-$(SUBMAKE) -C $(ASTERISK_DIR) $(ASTERISK_MAKE_PARAMS) clean" ändern.
In der chan_capi.mk-Datei muss auch geändert werden.

 

[PsychoMantis]

Es passt jetzt vielleicht nicht zum Thema, aber kann man Asterisk nicht so bauen, dass er nicht auf libpthread oder libncurses usw. angewiesen ist, sondern alles selbst beinhaltet?

 

[hermann72pb]

Das nennt sich statisch linken und wenn Asterisk es per see nicht kann, dann ist es keine leichte Aufgabe es ihm beizubringen. Die Paar Zeilen Code zu ändern, um es an die geänderten Örtlichkeiten von libraries zu verweisen dürfte deutlich leichter ausfallen.

MfG

 

[PsychoMantis]

Versuch mal Folgendes:

In der asterisk.mk-Datei alle "$(MAKE) -C $(ASTERISK_DIR)" in "$(SUBMAKE) -C $(ASTERISK_DIR)" ändern. Alle "PATH="$(TARGET_PATH)" löschen.
Auch "-$(MAKE) -C $(ASTERISK_DIR) $(ASTERISK_MAKE_PARAMS) clean" in "-$(SUBMAKE) -C $(ASTERISK_DIR) $(ASTERISK_MAKE_PARAMS) clean" ändern.

Habe ich versucht. Funktioniert nicht.
Kann ich dem Asterisk eigentlich auch mitteilen, dass z.B. die libncurses in /tmp/bla/ liegt?

 

[sf3978]

[...]
Kann ich dem Asterisk eigentlich auch mitteilen, dass z.B. die libncurses in /tmp/bla/ liegt?

Ja, mit einem symlink. Mach ein symlink auf die libncurses, in das Verzeichnis in dem der asterisk die libncurses z. Zt. noch sucht/findet.

 

[Silent-Tears]

Hast du make asterisk-dirclean gemacht nach deinen Änderungen?

 

[PsychoMantis]

@ silent-Tears: Ja, habe ich.
@ sf3978: Ja, das mit dem symlink ist mir klar. Ich meinte * so kompilieren, dass er in /tmp/bar sucht.
Nachtrag: Dein Tipp hier funktioniert doch.

 

[RalfFriedl]

Von mir noch eine Rückmeldung zum selbst Bauen der Toolchain:
Bei mir kam die Meldung, daß das Verzeichnis source/toolchain/target/gcc-4.3.3-uClibc-0.9.29/uClibc_dev/usr/include nicht existieren würde. Nach einigen dircleans habe ich dann die Toolchain mit FREETZ_JLEVEL=1 erstellt, das hat funktioniert.
Normalerweise habe ich FREETZ_JLEVEL=16. Ich habe zwar keine 16 CPUs, aber auf die Art merkt man eher, wenn es Probleme mit parallelem Make gibt.

Der aktuelle Anlaß für mich war das Problem mit openntpd und ifaddrs. Vorher war ifaddrs.h vorhanden, aber nicht die Funktion getifaddrs. Jetzt ist auch die Include-Datei nicht mehr vorhanden.

Die C-Library hat eine Funktion getifaddrs, aber diese verwendet netlink und ist anscheinend größer und deaktiviert.