On Mon, Dec 14, 2015 at 10:21:54PM +0000, Read, James C wrote:
> >>
> >> 2) By entering the following command sequence
> >>
> >>
> >> echo 'main(){}' | gcc -xc -v -Wl,-verbose -lrt - 2>&1 | grep libpthread
> >> libpthread.so.0 needed by
> >> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so
> >> found libpthread.so.0 at /lib/x86_64-linux-gnu/libpthread.so.0
> >> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
> >> `h_errno@GLIBC_PRIVATE'
>
> >Libpthread is found on the host instead of /mnt/lfs/tools. Since you tried
> >that command, I guess you read the message
> >http://lists.linuxfromscratch.org/pipermail/lfs-dev/2012-December/067457.html,
>
> >and maybe also the thread about check-0.9.9 in March 2013.
>
> >It looks like you used the right configure switches for binutils-pass2, so it
> >must come from something else. What bothers me is that it only occured in
> >perl. It seems that this should occur before whenever -lrt is passed to gcc.
>
> >Actually, in my log, I see "-lrt" in check, in coreutils, and in gettext
> >before perl. So maybe something happened before you tried to build perl (did
> >you log out and in, and then the PATH is not correctly set, or some other
> >envar?)
>
> Just checked. Everything is as it was from when I set up the build
> environment as the book instructs.
>
> Here is my env output
>
> TERM=xterm-256color
> OLDPWD=/mnt/lfs/sources
> LC_ALL=POSIX
> LFS=/mnt/lfs
> PATH=/tools/bin:/bin:/usr/bin
> PWD=/mnt/lfs/sources/perl-5.22.0
> LFS_TGT=x86_64-lfs-linux-gnu
> PS1=${debian_chroot:+($debian_chroot)}\u@\h:\w\$
> SHLVL=1
> HOME=/home/lfs
> _=/tools/bin/env
>
>
> >Also, in the command above, there is no reference to -lrt. When I search for
> >-lrt in the log, I only find it once:
> >---------
> >Configuring Time::HiRes...
> >Using hints hints/linux.pl...
> >Extra libraries: -lrt...
> >---------
> >So maybe it is in `cat ext.libs`.
>
> cat ext.libs
>
> gives the following output
>
> -lrt
>
> What does this mean? How do I fit it? Does this mean everything else is fine?
>
> >But I am almost sure that this error should have occured before in
> >coreutils...
>
> 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.
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 ?
And looking at random programs in /tools/bin (from glibc onwards),
are they linked to /tools/lib64 or to /lib ?
ĸ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
