On Sat, Dec 01, 2012 at 11:59:07PM +1300, Simon Geard wrote:
> On Fri, 2012-11-30 at 11:17 -0500, Chris Staub wrote:
> > First, check how Bash is linked: "readelf -l /bin/bash | grep
> > interpret". Of course, this should say that it's looking for the dynamic
> > linker in /lib. Then verify you actually have all the right libraries
> > for Ncurses: "ls -la {/usr,}/lib/*ncurses*"
>
> Yes, it's using /lib64/ld-linux-x86-64.so.2, and yes, the chapter 6
> version of ncurses *is* correctly installed. But that copy of ncurses is
> the wide-char version, and bash has managed, somehow, to link to the
> non-wide version. My assumption, as I said, is that instead of finding
> the linker scripts in /usr/lib which would point it to the wide version,
> it's found the non-wide version in /tools instead.
>
I don't remember seeing anything like this before.
In the distant past, I've had my own fun and games with ncurses when
I fubar'd some of the moves and symlinks. So, is your _wide_ version
of libncurses ok ?
I'm thinking perhaps something went wrong when you moved it to
/lib, so that the /usr/lib/libncursesw.so symlink is pointing to a
non-existent file.
Looking at my own *logs* from bash, it uses -lcurses so also check
that /usr/lib/libcurses.so is a symlink to libncurses.so.
If you ran the verification tests when you adjusted the toolchain,
and after installing gcc, then my money is on an error *after* that.
Of course, if you didn't run those checks (the SEARCH_DIR etc) then
all bets are off.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
