On Mon, Dec 14, 2015 at 11:43:56PM +0000, Read, James C wrote:
>
> >> tail from make log for coreutils
> >>
> >> make all-recursive
> >> make[3]: Entering directory '/mnt/lfs/sources/coreutils-8.24/gnulib-tests'
> >> Making all in .
> >> make[4]: Entering directory '/mnt/lfs/sources/coreutils-8.24/gnulib-tests'
> >> make[4]: Nothing to be done for 'all-am'.
> >> make[4]: Leaving directory '/mnt/lfs/sources/coreutils-8.24/gnulib-tests'
> >> make[3]: Leaving directory '/mnt/lfs/sources/coreutils-8.24/gnulib-tests'
> >> make[2]: Leaving directory '/mnt/lfs/sources/coreutils-8.24/gnulib-tests'
> >> make[1]: Leaving directory '/mnt/lfs/sources/coreutils-8.24'
> >>
> >For coreutils in chapter 5, -lrt is certainly tested for, in the
> >output from configure, specifically at lines 778 and 863 in my logs:
>
> >checking for library containing timer_settime... -lrt
> >and
> >checking for sched_yield in -lrt... yes
>
> >I suppose that coreutils might regard this as optional - if you
> >logged configure, you can see if it found it.
>
> In my coreutils configure log I have the following line:
>
> checking for sched_yield in -lrt... no
>
So, coreutils apparently did not find a working version of librt.
> >Do you actually have any, or all, of
> >/tools/lib/librt-2.22.so
> >/tools/lib/librt.a
> >/tools/lib/librt.so
> >/tools/lib/librt.so.1 ?
>
> I have all of them:
>
> ls /tools/lib/librt*
> /tools/lib/librt-2.22.so /tools/lib/librt.a /tools/lib/librt.so
> /tools/lib/librt.so.1
> ls /tools/lib64/librt*
> /tools/lib64/librt-2.22.so /tools/lib64/librt.a /tools/lib64/librt.so
> /tools/lib64/librt.so.1
>
I was going to suggest you ran ldd on the shared versions (on x86_64
a static libfoo.a cannot normally be linked into a shared
executable), but I think you have already confirmed the problem in
your next reply.
> >And looking at random programs in /tools/bin (from glibc onwards),
> >are they linked to /tools/lib64 or to /lib ?
>
> Sorry for the long output to follow. It seems everything is linked to
> /tools/lib64.
>
I might be wrong, and I don't have a completed version of /tools
anywhere nearby, but I disagree.
> find /tools/bin/ -type f -perm /a+x -exec ldd {} \;
> linux-vdso.so.1 => (0x00007fff4971f000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd0cea3c000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd0ce672000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So at least one program in /tools/bin links to the host's libc.
> /lib64/ld-linux-x86-64.so.2 (0x00007fd0cec40000)
and it also uses the host's loader
> linux-vdso.so.1 (0x00007ffc4030d000)
> libpthread.so.0 => /tools/lib/libpthread.so.0 (0x00007f8bf9f37000)
> libc.so.6 => /tools/lib/libc.so.6 (0x00007f8bf9b93000)
> /tools/lib64/ld-linux-x86-64.so.2 (0x00007f8bfa154000)
Whereas that program looks ok
You seem to have a mix of binaries using /tools and binaries using
the host's /lib. Try something like (off the top of my head)
for P in /tools/bin/* ; do
echo $P ; ldd $P | grep ' /lib/' ; done
If I haven't fubar'd it, that should produce a list of all programs
in /tools/bin, with some lines mentioning ' /lib/'. Look at the
programs which generate those lines, then look at the first one,
identify which package it came from (details are in chapter 6, or
use google), and repeat.
You should probably also run ldd on the .so libs in /tools/lib, in
case any of those link to /usr.
You can then identify which package or packages are linked to libs
on the host. After that, you need to review what you did, until you
can work out why it went wrong. It looks as if you left at some
point, and then resumed without everything being set up correctly.
ĸen
--
This email was written using 100% recycled letters.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
