[lfs-support] glibc tests errors
zarniwhoop at ntlworld.com
Mon Jan 2 12:24:42 PST 2012
On Mon, Jan 02, 2012 at 07:57:49PM +0200, mais lfs wrote:
> On Mon, Jan 2, 2012 at 7:24 PM, Ken Moffat <zarniwhoop at ntlworld.com> wrote:
> > Take a look in glibc-check-log from the *host* system.
> Don't have 'less' available yet, so is using:
> grep -B5 Error glibc-check-log
I know you don't have less or vim in chroot, that's why I said to
use it from the host. But, you've found the error.
> with which I found:
> error while loading shared libraries: libgcc_s.so.1: cannot open shared
> object file: No such file or directory
> but: find / -name 'libgcc_s*' gives
To confirm the problem, your really DO have to go back to the host
system, then run ldd /mnt/lfs/tools/lib/libgcc_s.so.1
I'm guessing it's linked against one or more host libraries in
/usr/lib. If so, something went badly wrong.
I'm not in favour of the 'repeat, hoping it will work this time',
approach. I do think you will have to start again, from the
beginning, but if you can gather information about what you did
wrong, you will know what to do differently next time.
The problem with (only) libgcc_s doesn't ring any bells for me. I
wonder if in fact other packages in chapter 5 have been linked to
the host. You can try running ldd on some binaries in /tools/bin and
some shared libraries in /tools/lib - pick one of either from each
package, starting with binutils pass 2 (section 5.9) and then for
random later packages.
If they are all linked to /usr/lib, something went wrong in section
5.8, 'Adjusting the Toolchain'. If the problem is only with some,
or all, packages after binutils pass 2, then I suspect you took a
break, but didn't correctly restore the environment when you
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-support