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. > > You could also just upload your build scripts for Ncurses, Readline, and > Bash. I don't think there's anything wrong with how those packages have been built - the scripts are just copy-paste from the book, with the usual wrapper code for extracting tarballs and cleaning up afterwards. I suspect the problem is something to do with the linker changes done in "Adjusting the Toolchain", but I can't see anything obvious that I've missed there either. Basically, I'm hoping that someone more familiar than me with the toolchain can tell me how a chapter 6 package (bash) might be linked against a library not installed in chapter 6 (the non-wide version of ncurses). The obvious answer is that it's found the version built in chapter 5, but what could cause that? Simon.
signature.asc
Description: This is a digitally signed message part
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
