> I've read through the thread. What you should have is:
>
> # find / -name libz.so\* -ls
>
> lrwxrwxrwx root 23 /usr/lib/libz.so -> ../../lib/libz.so.1.2.8
> -rwxr-xr-x root 113344 /lib/libz.so.1.2.8
> lrwxrwxrwx root 13 /lib/libz.so.1 -> libz.so.1.2.8
>
Yes, that is exactly what I have.
> (slightly edited to fit)
>
> If you don't have that, make it so:
>
> # ln -sfvn ../../lib/libz.so.1.2.8 /usr/lib/libz.so
> # ln -sfvn libz.so.1.2.8 /lib/libz.so.1
>
> Then tell the system to be sure:
>
> # ldconfig
>
Done.
> Also check the library:
>
> # file /lib/libz.so.1.2.8
> /lib/libz.so.1.2.8: ELF 64-bit LSB shared object, x86-64, version 1
> (SYSV), dynamically linked, not stripped
>
I have the same here.
> If you still get the error that it can't find libz.so.1, then you have a
> fairly serious problem. It's not a kmod issue, but a more general
> problem.
>
Unfortunately, I still have it...
> You can check with a test program:
>
> $ cat > ztest.c << EOF
> #include <zlib.h>
> #include <stdio.h>
>
> int main()
> {
> const char* v = zlibVersion();
> printf( "zlib version is %s\n", v );
> }
> EOF
>
> $ gcc -o ztest -lz ztest.c
> $ ./ztest
> zlib version is 1.2.8
>
>
I run the program and the result was exactly the same you have:
root:/tmp# ./ztest
zlib version is 1.2.8
When you say that this could be a "fairly serious problem" do you mean that
maybe this could lead to a complete wipe out and start over again? I ask it
because I have not yet the experience in building a lfs system in order to
accurately find a possible restart point...(I mean, to know if this error is
related to something that went wrong in ch 6 or ch5 and start from there again).
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
