Error in NCURSES-5.7 Procedure?

alupu alupu02 at gmail.com
Fri May 1 11:30:32 PDT 2009


Hi,

If true, this should go to the attention of LFS Developers.
If specific to my type configuration, maybe in a Wiki,
to whom it may concern.
If wrong, please disregard.

Before installing the 5.7, on my ncurses-5.4 system
(circa Oct. 2005), I had this chain of five links:

/usr/lib/libncurses.so.5 -> /usr/lib/libcurses.so ->
/usr/lib/libncurses.so -> /lib/libncurses.so.5 ->
/lib/libncurses.so.5.4

Crazy, but I suppose it was left like that after the
ncurses-5.4 procedure (and it worked for me).

Unfortunately, some important applications rely on
'/usr/lib/libncurses.so.5' (ldd ...) such as
'vi' (7.2), 'less' (382) and BASH (3.2.15).

In the 5.7 procedure, at the 'for' loop:

for lib in curses ncurses form panel menu ; do \
    rm -vf /usr/lib/lib${lib}.so ; \
    echo "INPUT(-l${lib}w)" >/usr/lib/lib${lib}.so ; \
    ... ,

the nice chain above is broken by the removal of
'/usr/lib/libcurses.so', thus leaving
'/usr/lib/libncurses.so.5' dangling hopelessly.

For anybody with my type of configuration the system
becomes unusable at this point, both as unable to
run 'vi' or 'less' (for example, to follow the procedure)
and because it crashes on 'bash's untimely death.

A solution I humbly offer is to run something like
ln -sfv /lib/libncurses.so.5 /usr/lib/libncurses.so.5
just before the 'for' loop
(in '/lib', libncurses.so.5 -> libncurses.so.5.4
which is still serviceable.)

Fortunately, this temporary work-around will be fixed
properly and painlessly just before the end of the
procedure, on the "non-wide" copy:
cp -av lib/lib*.so.5* /usr/lib

While at it, I also suggest replacing the above copy with
mv -fv ..
which saves some grief for those who use
alias cp='cp -i'
and, more importantly, preserves the original ("compile")
time of the 'libncurses.so.5' symlink.

Thank you for your consideration,
-- Alex



More information about the lfs-support mailing list