On Sun, Sep 24, 2006 at 03:34:13PM +0400, Vladimir A. Pavlov wrote:
> Hi!
>
> I've been building a SVN (20060918) version of CLFS and have gone to
> the chapter "10.15. Ncurses-5.5". As I've successfully built LFS before
> I note two differences from it: CLFS doesn't use
> ncurses-5.5-fixes-1.patch and --enable-widec flag when configuring.
>
> So, my questions are:
> 1. Is there a reason why CLFS does it in its own way?
The widec build went into LFS as part of Alexander's UTF-8 changes.
Some of the other changes (e.g. an older groff, man-db) are not
popular. I think the summary for i18n on CLFS was "it distracts us
from getting a release out, and the next groff should solve most of
the problems" - apologies if I got that wrong.
> 2. If no, can I build ncurses (in "Building the CLFS System") exactly
> as LFS suggests?
>
Not exactly. I'm playing with ncurses at the moment (I was going
to keep quiet until I'd finished the base systems and learned
exactly how much ncursesw gives me - that could be several days
away). I think LFS changed how ncurses was built before the widec
changes, which alters how the /lib /usr/lib part gets sorted out.
The following instructions appear to work. I've built both x86_64-64
and ppc64 to the end of chapter 11, but not the new kernel nor the
extras I need before I boot).
For /lib (non-multilib, and 32-bit)
(i.) add --enable-widec to configure
(ii.) after make install, change the mv, rm ln, chmod instructions
to
mv -v /lib/lib{panelw,menuw,formw,ncursesw,ncurses++w}.a /usr/lib
rm -v /lib/lib{ncursesw,menuw,panelw,formw,cursesw}.so
ln -svf ../../lib/libncursesw.so.5 /usr/lib/libcursesw.so
ln -svf ../../lib/libncursesw.so.5 /usr/lib/libncursesw.so
ln -svf ../../lib/libmenuw.so.5 /usr/lib/libmenuw.so
ln -svf ../../lib/libpanelw.so.5 /usr/lib/libpanelw.so
ln -svf ../../lib/libformw.so.5 /usr/lib/libformw.so
chmod -v 755 /lib/lib{panelw,menuw,formw,ncursesw}.so.5.5
(iii.) the remove and replace non-wide instructions as in LFS
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 ; \
ln -sfv lib${lib}w.a /usr/lib/lib${lib}.a ; \
done
(iv.) the fix for apps looking for -lncurses is slightly different.
Our /usr/lib/libcursesw.so is a symlink, echoing into it will
overwrite the real library so we need to remove it first. I haven't
looked at the detail to work out why LFS doesn't have to do the rm,
but getting it wrong is a real showstopper (on multilibs, the 64-bit
install fails trying to run tic, on 'monolib' procps fails to link).
ln -sfv libncurses++w.a /usr/lib/libncurses++.a
rm -vf /usr/lib/libcursesw.so
echo "INPUT(-lncursesw)" >/usr/lib/libcursesw.so
ln -sfv libncurses.so /usr/lib/libcurses.so
ln -sfv libncursesw.a /usr/lib/libcursesw.a
ln -sfv libncurses.a /usr/lib/libcurses.a
(v.) I can see no compelling reason to do the non-wide build
mentioned in the Note in LFS.
For /lib64 do the same, but changing every /lib above to /lib64.
Now that this is on the record, I'll reply to this after I've
determined what it brings to the party - I'm hoping for better
display of characters in vim and mutt, but I suspect an absence
of fonts is the main problem.
Ken
> --
> Nothing but perfection
> pv
> _______________________________________________
> Clfs-support mailing list
> [email protected]
> http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
--
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
