[gelöst] ncurses-5.7

astrapi

Mitglied
Mitglied seit
27 Mai 2005
Beiträge
341
Punkte für Reaktionen
0
Punkte
0
Hi, habe Probleme mit svn3505 und ncurses-5.7. Beim bauen der ncurses bleibt der Vorgang einfach stehen. Leider keine Fehlermeldung.

Denke http://trac.freetz.org/ticket/497 bezeichnet obigen Fehler.
 
Zuletzt bearbeitet:
mhm hab mal versucht die 4 diffs vom ticket einzuspielen aber hängt immer noch nach:

Code:
make[2]: Entering directory `/home/slightly/freetz/trunk/source/ncurses-5.7/misc'
/usr/bin/install -c ncurses-config /home/slightly/freetz/trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/bin/ncurses5-config
make[2]: Leaving directory `/home/slightly/freetz/trunk/source/ncurses-5.7/misc'

Beim File ...build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib/libncurses.so.5.7

Greetz,
Nord
 
Ich kann das Problem hier nicht nachstellen.
@astrapi: Poste mal bitte die Ausgabe von:
Code:
make ncurses-dirclean && make ncurses-precompiled
@N0rdmann: Die 4 Patches einzuspielen ist auch keine sinnige Idee, man guckt erst einmal ,was sie bewirken, bevor man das tut. Somit bitte die Patches reverten, ein "svn up" machen, und obiges auch das Ergebnis von
Code:
make ncurses-dirclean && make ncurses-precompiled
posten.
 
das Ergebniss:

Code:
mipsel-linux-ranlib /home/michael/projekte/freetz/7270_dev/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib/libform.a
installing ./form.h in /home/michael/projekte/freetz/7270_dev/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include
make[2]: Leaving directory `/home/michael/projekte/freetz/7270_dev/source/ncurses-5.7/form'
cd test && make DESTDIR="/home/michael/projekte/freetz/7270_dev/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc" install.libs
make[2]: Entering directory `/home/michael/projekte/freetz/7270_dev/source/ncurses-5.7/test'
make[2]: Für das Ziel »install.libs« ist nichts zu tun.
make[2]: Leaving directory `/home/michael/projekte/freetz/7270_dev/source/ncurses-5.7/test'
cd misc && make DESTDIR="/home/michael/projekte/freetz/7270_dev/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc" install.libs
make[2]: Entering directory `/home/michael/projekte/freetz/7270_dev/source/ncurses-5.7/misc'
/usr/bin/install -c ncurses-config /home/michael/projekte/freetz/7270_dev/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/bin/ncurses5-config
make[2]: Leaving directory `/home/michael/projekte/freetz/7270_dev/source/ncurses-5.7/misc'
 
@Silent-Tears
Hab halt mal blauäugig gehofft die 2 patches von markuschen wären direkt auf das Problem bezogen, und die 2 weiteren hatte er ja noch nachgereicht da external? vergessen wurde...

Auch nach make ncurses-dirclean && make ncurses-precompiled kein unterschied, hängt wieder nachdem er das Verzeichniss misc verlässt

Hab vorher extra nochmal neu komplett ausgecheckt, Rev. 3511
hab mal den kompletten output unten als Attachment angehängt

@RalfFriedl
Auf Deutsch steht oben zu beginn des Threads:
Beim bauen der ncurses bleibt der Vorgang einfach stehen. Leider keine Fehlermeldung.
Hab ja geschrieben er hängt genau nach dem geposteten Output.


**edit**
Vllt. ist das hängen auch ein hausgemachtes Problem durch verwendung von StinkyLinux bzw. VMWare?
Habs aufjedenfall mal ne Stunde laufen gehabt, keine Veränderung zu sehen, es hängt scheinbar tic mit 100% cpu

**update**
nach einem einfachen make nach dem letzten Versuch mit ncurses-precompiled kommt der output diesmal etwas weiter...
Habe keine Erklärung für das verhalten aber hier mal die Ausgabe:
Code:
make[1]: Entering directory `/home/slightly/freetz/trunk/source/ncurses-5.7/misc'
make[1]: Für das Ziel »all« ist nichts zu tun.
DESTDIR=/home/slightly/freetz/trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc \
        prefix=/usr \
        exec_prefix=/usr \
        bindir=/usr/bin \
        top_srcdir=.. \
        srcdir=. \
        datadir=/usr/share \
        ticdir=/usr/share/terminfo \
        source=terminfo.tmp \
        THIS_CC="/home/slightly/freetz/trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc" \
        THAT_CC="gcc" \
        /bin/sh ./run_tic.sh
/usr/bin/install -c ncurses-config /home/slightly/freetz/trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/bin/ncurses5-config
** Building terminfo database, please wait...
Running tic to install /home/slightly/freetz/trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/share/terminfo ...

        You may see messages regarding extended capabilities, e.g., AX.
        These are extended terminal capabilities which are compiled
        using
                tic -x
        If you have ncurses 4.2 applications, you should read the INSTALL
        document, and install the terminfo without the -x option.
Scheint also wirklich am hängendem tic zu liegen, ich lass das mal so nochmal ne weile laufen.

Greetz
 

Anhänge

  • output.zip
    20.3 KB · Aufrufe: 1
Zuletzt bearbeitet:
Es hat definitiv etwas mit der neuen ncurses Version zu tun. Wenn Ihr nach dem aktuellen "svn up" auf 3511 seit, dann geht bitte einmal in das Freetz-Verzeichnis unter make/libs/ncurses.mk und gebt dort, in der ersten Zeile 5.6 anstatt 5.7 für das make zu ncurses ein. Schon klappt es wieder mit dem erstellen, der Freetzimages.
 
geht bitte einmal in das Freetz-Verzeichnis unter make/libs/ncurses.mk und gebt dort, in der ersten Zeile 5.6 anstatt 5.7 für das make zu ncurses ein. Schon klappt es wieder mit dem erstellen, der Freetzimages.
THX für den Workarround, hatte auch schon was in google von Problemen mit ncurses 5.7 gelesen, konnte das aber nich zuordnen.
Dann hoffen wir mal das 5.7 nix neues bringt was von irgendeinem Programm benötigt wird?

Greetz
 
Dann hofft mal lieber, dass es überhaupt sauber funktioniert, denn es gehören imho Patches zu ncurses dazu, die sich geändert haben.
Lieber sucht mal ein wenig im SVN-Howto herum, wie ihr einzelne Verzeichnisse auf einen anderen Revisionsstand bekommt, und somit alles kirrekt fabriziert für die 5.6

Dennoch ist es wenig hilfrech, wenn jeder irgendwas macht, um das PRoblem zu umgehen, ohne es weiter anzugehen, bzw. einzugrenzen.

Interessant wäre wirklich die Theorie ob der buildumgebung. Wenn man das unter Stinky fabriziert, vllt. mal das freetz-linux verwenden, oder gleicvh ein natives Linux, was eh noch ein Stück sinniger ist.
 
Also ich denke nicht das es an der Buildumgebung liegt. Zur Info, ich benutze openSUSE 11.1 64bit über virtualbox 3.0.2.
 
Also ich denke nicht das es an der Buildumgebung liegt.

Dann frage ich mich, wieso es bei mir unter gentoo ~x86_64 und unter (k)ubuntu x86_64 läuft, ebenso auf meinem debian sid.
 
in der Tat komisch, ist Stinky nicht debian?

edit: werde es gleich mal unter ubuntu testen
 
Ich mag keine diskussion hier anstreben, aber Stinky ist und bleibt inzwischen echt veraltet, wennman keinen Plan hat, wie man das vernünftig aktualisiert. Über die Release-Zyklen und Versionierungen findest du wohl am ehesten was bei Debian raus....
 
wollt damit nur andeuten das es ja gehen müsste, wenn bei dir debian geht
 
Also ich denke nicht das es an der Buildumgebung liegt. Zur Info, ich benutze openSUSE 11.1 64bit über virtualbox 3.0.2.
Ja war auch nur so ein Gedanke, denke mittlerweile auch eher es ist ein Problem mit ncurses 5.7

Dann frage ich mich, wieso es bei mir unter gentoo ~x86_64 und unter (k)ubuntu x86_64 läuft, ebenso auf meinem debian sid.
Wirklich sehr merkwürdig, gerade für gentoo habe ich z.b. den gleichen Fehler in einem bugreport gefunden - sys-libs/ncurses-5.7: hangs after /bin/sh ./run_tic.sh and eats up almost all cpu http://bugs.gentoo.org/249363

in der Tat komisch, ist Stinky nicht debian?
korrekt
 
Debian ist nicht gleich debian. Alles andere ist hier deplaziert.
 
Debian ist nicht gleich debian. Alles andere ist hier deplaziert.
und das letzte Posting hilft uns jetzt wie weiter....?
Ist doch jetzt ziemlich wahrscheinlich das es an ncurses 5.7 liegt und nicht zwingend an stinky - da bisher auch unter OpenSuse und Gentoo exakt das gleiche Problem aufgetreten ist
 
ja, es geht hier um freetz und nicht darum welche buildumgebung die bessere ist
 
Man, kinners. Mein Kommantar bezieht sich darauf, dass ein debian sid eben kein debian lenny is, wie das stinky-ding. Ich persönlich baue eben erfolgreich auf einem ubuntu-system. Somit muss bei mir im gegensatz zu euren Umgebungen irgendetwas anders sein, denn selbst ein sauberer neuer Checkout mit und ohne selfmade-toolchain funktionieren hier.
 
liegt es vielleicht an der paketauswahl?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.