Re: [lfs-support] Help with a linker problem
On Sun, 2012-12-02 at 15:01 +1300, Simon Geard wrote: I think Ken has pointed me in the right direction - bash links not to libncurses or libncursesw, but to plain-old libcurses, and I seem to have missed the commands that create the linker script that redirects that one. I've just fixed it, and kicked off a fresh build to see if it worked. And just to confirm, that was it. Not a problem with the linker like I'd assumed - just a missed step in the ncurses build. Seeing as it was complaining about libncurses (rather than libcurses) not being found, it never occurred to me to double-check 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
Re: [lfs-support] Help with a linker problem
On Sun, 2012-12-02 at 21:14 +1300, Simon Geard wrote: And just to confirm, that was it. Not a problem with the linker like I'd assumed - just a missed step in the ncurses build. Seeing as it was complaining about libncurses (rather than libcurses) not being found, it never occurred to me to double-check that. Sigh... turns out there *was* something significantly wrong with the linker, which I only discovered on nuking /tools after the build finished successfully. Installing the chapter 6 binutils into /tools really doesn't help... 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
Re: [lfs-support] Help with a linker problem
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
Re: [lfs-support] Help with a linker problem
On Dec 1, 2012, at 4:59 AM, Simon Geard wrote: 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? You can run strace -f chroot command and see what is going on. Also follow this: http://www.linuxfromscratch.org/lfs/view/stable/chapter06/adjusting.html Do your results of those commands look good? Is /lib and /usr/lib linked properly to /lib64 and /usr/lib64 ? Since you can't chroot anymore with a broken /bin/bash, redo the / tools/bin/bash link to /bin/bash as in this section: http://www.linuxfromscratch.org/lfs/view/stable/chapter06/createfiles.html Next, do your scripts remove all build and source directories after each install in ch5 and ch6? Have you done a successful build without using scripts? If so, you can do it again and check your history with your scripts. You can upload the scripts somewhere and we can look at them. Sincerely, William Harrington-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
On Nov 30, 2012, at 5:37 AM, Simon Geard wrote: /bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory Do you also get the same problem when running /bin/more /sbin/cfdisk and /usr/bin/cal ? Those are installed by util-linux which is before bash and after ncurses. You can try psmisc's /usr/bin/pstree and see if it is having issues with libncursesw Then procps utils like /usr/bin/top and /usr/bin/watch If those are not okay, then something before ncurses is the problem I suspect. Sincerely, William Harrington-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
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
Re: [lfs-support] Help with a linker problem
On Sat, 01 Dec 2012 23:59:07 +1300
Simon Geard delga...@ihug.co.nz 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.
Can you do `ldd /bin/bash'?
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
On Sat, 1 Dec 2012 16:19:38 +0100
Aleksandar Kuktin akuk...@gmail.com wrote:
On Sat, 01 Dec 2012 23:59:07 +1300
Simon Geard delga...@ihug.co.nz 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.
Can you do `ldd /bin/bash'?
I mean `ldd /path/to/bash/that/is/the/problem/bash'.
Also, there is an easy way to test if the problem is linking with a
library from /tools. Make a symlink.
ln -sv /usr /tools
Then try it again.
--
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
On Sat, 1 Dec 2012 16:24:08 +0100 Aleksandar Kuktin akuk...@gmail.com wrote: I mean `ldd /path/to/bash/that/is/the/problem/bash'. Also, there is an easy way to test if the problem is linking with a library from /tools. Make a symlink. ln -sv /usr /tools Then try it again. Or maybe you can upload the offending bash binary. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with a linker problem
On Sat, 2012-12-01 at 16:19 +0100, Aleksandar Kuktin wrote: Can you do `ldd /bin/bash'? Oddly, no. I can't use ldd because that's a shell script depending on /bin/sh working, but if I run: /lib/ld-linux-x86-64.so.2 --list /bin/bash ...I get: /bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory That's kind of surprising, actually, because I'd expect it to just list all the libraries it's linked to, but flag one of them as unresolved. But if I run the copy of ld-linux under /tools, I get: $ /tools/lib/ld-linux-x86-64.so.2 --list /bin/bash linux-vdso.so.1 (0x7fffe3db7000) libncurses.so.5 = /tools/lib/libncurses.so.5 (0x7f3a543b2000) libdl.so.2 = /tools/lib/libdl.so.2 (0x7f3a541ae000) libc.so.6 = /tools/lib/libc.so.6 (0x7f3a53e08000) /lib64/ld-linux-x86-64.so.2 = /tools/lib/ld-linux-x86-64.so.2 (0x7f3a54602000) 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
Re: [lfs-support] Help with a linker problem
On Sat, 2012-12-01 at 07:27 -0600, William Harrington wrote: On Nov 30, 2012, at 5:37 AM, Simon Geard wrote: /bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory Do you also get the same problem when running /bin/more /sbin/cfdisk and /usr/bin/cal ? Those are installed by util-linux which is before bash and after ncurses. No I don't. But build logs show that those are being linked directly to libncursesw instead of through the linker script. I think Ken has pointed me in the right direction - bash links not to libncurses or libncursesw, but to plain-old libcurses, and I seem to have missed the commands that create the linker script that redirects that one. I've just fixed it, and kicked off a fresh build to see if it worked. 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
[lfs-support] Help with a linker problem
Hey guys... Rewriting my LFS build scripts, I'm getting an interesting linking error with bash in chapter 6, and am hoping someone can point me in the right direction for tracking down the cause. Basically, bash builds correctly, but the resulting binary is bad, any attempt to invoke it resulting in: # /bin/bash --version /bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory Now, the obvious problem is that it's complaining about libncurses, not the libncursesw version built in chapter 6. As far as I can tell, it should be linked to the latter, thanks to the INPUT(-lncursesw) linker script created when we installed ncurses. My suspicion is that when the bash binary was linked, the linker found ncurses in /tools ahead of /lib, and so not applied that linker script. It then fails runtime linking, since /tools isn't in the search path at runtime (unless I put it there with LD_LIBRARY_PATH). So, it seems pretty clear that I've missed something in my script - probably in one of those first few parts of chapter 6. But I can't spot the problem myself, so I'm hoping someone can point me in the direction of what could be causing this. 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
