Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-19 Thread Thanos Baloukas 

On 19/12/2015 09:24 μμ, Thanos Baloukas wrote:

On 19/12/2015 07:59 μμ, Jose Angel Fernandez wrote:




It should be that /bin/bash, not /bin/dash is the active shell.



I have the same problem and reading the messages I've found that my link
was to dash instead of bash. Which is the best way to solve the problem?
Recompiling from pass 1 or pass 2?



It would be safer to start from the beginning.


Sorry, wrong expression.
There are people that changed the /bin/sh symlink after they had started 
the built
and because of that they had failures later. So I advise to definitely 
start from the beginning.


--
Thanos
--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-19 Thread Thanos Baloukas 

On 19/12/2015 07:59 μμ, Jose Angel Fernandez wrote:




It should be that /bin/bash, not /bin/dash is the active shell.



I have the same problem and reading the messages I've found that my link
was to dash instead of bash. Which is the best way to solve the problem?
Recompiling from pass 1 or pass 2?



It would be safer to start from the beginning.

--
Thanos
--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-19 Thread Jose Angel Fernandez 

> >
> > It should be that /bin/bash, not /bin/dash is the active shell.
> >

I have the same problem and reading the messages I've found that my link 
was to dash instead of bash. Which is the best way to solve the problem? 
Recompiling from pass 1 or pass 2?




-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-17 Thread Pierre Labastie 

On 17/12/2015 18:14, Read, James C wrote:

Does this all look good?



It seems so. I suggest you build gcc-pass2, and then try the test I have
proposed on -dev. Of course, the more thorough tests proposed by Ken can
be used too.

output of your test

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 /tools/lib/libpthread.so.0

looking good?
I think so... If you always set the envars correctly (LFS), and do not 
miss an instruction, everything should be fine from now on.


Pierre
--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-17 Thread Pierre Labastie 

On 17/12/2015 16:16, Read, James C wrote:

I just checked again with a test build, I get the same results. All the
$LFS_TGT-* binaries do still link to /lib as they're the ones from the first
pass, so that should be nothing to worry about. Still, you are missing the
programs that should have been installed by Binutils Pass 2, so I would check
those commands very carefully against what's in the book, including verifying
that you did in fact remove the source and build directories between Pass 1
and Pass 2.

Chris, I think you spotted the right issue: even the binutils executables
prefixed with x86_64-unknown-linux-gnu- are not in James' /tools/bin. It looks
like the "make install" step, before "make -C ld clean", was missed in
binutils-pass2.

I've just rebuilt binutils. Here is my output of files created today:

ls -al /tools/bin/ | grep 'Dec 17'
drwxr-xr-x  2 lfs lfs12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root4096 Dec 17 13:05 ..
-rwxr-xr-x  1 lfs lfs  5307288 Dec 17 14:38 addr2line
-rwxr-xr-x  2 lfs lfs  5470840 Dec 17 14:38 ar
-rwxr-xr-x  2 lfs lfs  7456632 Dec 17 14:38 as
-rwxr-xr-x  1 lfs lfs  5265576 Dec 17 14:38 c++filt
-rwxr-xr-x  1 lfs lfs94576 Dec 17 14:38 elfedit
-rwxr-xr-x  1 lfs lfs  5829208 Dec 17 14:38 gprof
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld
-rwxr-xr-x  1 lfs lfs  7489760 Dec 17 13:22 ld-new
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld.bfd
-rwxr-xr-x  2 lfs lfs  5340912 Dec 17 14:38 nm
-rwxr-xr-x  2 lfs lfs  6284816 Dec 17 14:38 objcopy
-rwxr-xr-x  2 lfs lfs  7802816 Dec 17 14:38 objdump
-rwxr-xr-x  2 lfs lfs  5470832 Dec 17 14:38 ranlib
-rwxr-xr-x  1 lfs lfs  1287424 Dec 17 14:38 readelf
-rwxr-xr-x  1 lfs lfs  5296808 Dec 17 14:38 size
-rwxr-xr-x  1 lfs lfs  5296624 Dec 17 14:38 strings
-rwxr-xr-x  2 lfs lfs  6284840 Dec 17 14:38 strip
lfs@ubuntu:/mnt/lfs/sources/build$ ls -al /tools/lib/ | grep 'Dec 17'
drwxr-xr-x 10 lfs lfs 12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root 4096 Dec 17 13:05 ..
-rw-r--r--  1 lfs lfs  13939338 Dec 17 14:38 libbfd.a
-rwxr-xr-x  1 lfs lfs   882 Dec 17 14:38 libbfd.la
-rw-r--r--  1 lfs lfs   2537748 Dec 17 14:38 libopcodes.a
-rwxr-xr-x  1 lfs lfs   889 Dec 17 14:38 libopcodes.la

Actually, I've said something wrong in my post (above), sorry. It is 
normal that there are no binutils executables prefixed with 
x86_64-unknown-linux-gnu- (I do not have them in my last build of LFS, 
which went to completion without error).


Pierre
--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-17 Thread Read, James C 
>>
>> Does this all look good?
>>
>>
>It seems so. I suggest you build gcc-pass2, and then try the test I have
>proposed on -dev. Of course, the more thorough tests proposed by Ken can
>be used too.

output of your test

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 /tools/lib/libpthread.so.0

looking good?
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-17 Thread Pierre Labastie 

On 17/12/2015 16:16, Read, James C wrote:

I just checked again with a test build, I get the same results. All the
$LFS_TGT-* binaries do still link to /lib as they're the ones from the first
pass, so that should be nothing to worry about. Still, you are missing the
programs that should have been installed by Binutils Pass 2, so I would check
those commands very carefully against what's in the book, including verifying
that you did in fact remove the source and build directories between Pass 1
and Pass 2.

Chris, I think you spotted the right issue: even the binutils executables
prefixed with x86_64-unknown-linux-gnu- are not in James' /tools/bin. It looks
like the "make install" step, before "make -C ld clean", was missed in
binutils-pass2.

I've just rebuilt binutils. Here is my output of files created today:

ls -al /tools/bin/ | grep 'Dec 17'
drwxr-xr-x  2 lfs lfs12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root4096 Dec 17 13:05 ..
-rwxr-xr-x  1 lfs lfs  5307288 Dec 17 14:38 addr2line
-rwxr-xr-x  2 lfs lfs  5470840 Dec 17 14:38 ar
-rwxr-xr-x  2 lfs lfs  7456632 Dec 17 14:38 as
-rwxr-xr-x  1 lfs lfs  5265576 Dec 17 14:38 c++filt
-rwxr-xr-x  1 lfs lfs94576 Dec 17 14:38 elfedit
-rwxr-xr-x  1 lfs lfs  5829208 Dec 17 14:38 gprof
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld
-rwxr-xr-x  1 lfs lfs  7489760 Dec 17 13:22 ld-new
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld.bfd
-rwxr-xr-x  2 lfs lfs  5340912 Dec 17 14:38 nm
-rwxr-xr-x  2 lfs lfs  6284816 Dec 17 14:38 objcopy
-rwxr-xr-x  2 lfs lfs  7802816 Dec 17 14:38 objdump
-rwxr-xr-x  2 lfs lfs  5470832 Dec 17 14:38 ranlib
-rwxr-xr-x  1 lfs lfs  1287424 Dec 17 14:38 readelf
-rwxr-xr-x  1 lfs lfs  5296808 Dec 17 14:38 size
-rwxr-xr-x  1 lfs lfs  5296624 Dec 17 14:38 strings
-rwxr-xr-x  2 lfs lfs  6284840 Dec 17 14:38 strip
lfs@ubuntu:/mnt/lfs/sources/build$ ls -al /tools/lib/ | grep 'Dec 17'
drwxr-xr-x 10 lfs lfs 12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root 4096 Dec 17 13:05 ..
-rw-r--r--  1 lfs lfs  13939338 Dec 17 14:38 libbfd.a
-rwxr-xr-x  1 lfs lfs   882 Dec 17 14:38 libbfd.la
-rw-r--r--  1 lfs lfs   2537748 Dec 17 14:38 libopcodes.a
-rwxr-xr-x  1 lfs lfs   889 Dec 17 14:38 libopcodes.la

and if I've got this right here are the linked libraries

for F in /tools/bin/* ; do  modsecs=$(date --utc --reference=$F +%s); 
nowsecs=$(date +%s); delta=$(($nowsecs-$modsecs)); if [ $delta -lt 12000 ]; 
then echo $F; ldd $F; fi; done
/tools/bin/addr2line
linux-vdso.so.1 (0x7fffde7c6000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f1d420a1000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f1d41cfd000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f1d422a5000)
/tools/bin/ar
linux-vdso.so.1 (0x7fff8b7e3000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f574419)
libc.so.6 => /tools/lib/libc.so.6 (0x7f5743dec000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f5744394000)
/tools/bin/as
linux-vdso.so.1 (0x7ffdfcb8)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fa3a2132000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fa3a1d8e000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fa3a2336000)
/tools/bin/c++filt
linux-vdso.so.1 (0x7ffc73bb9000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fb0ca441000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fb0ca09d000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fb0ca645000)
/tools/bin/elfedit
linux-vdso.so.1 (0x7ffd595cf000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fbd87124000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fbd86d8)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fbd87328000)
/tools/bin/gprof
linux-vdso.so.1 (0x7ffd354cc000)
libm.so.6 => /tools/lib/libm.so.6 (0x7fcad0f1b000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fcad0d17000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fcad0973000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fcad1219000)
/tools/bin/ld
linux-vdso.so.1 (0x7ffdbad8d000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f3c4103b000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f3c40c97000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f3c4123f000)
/tools/bin/ld-new
linux-vdso.so.1 (0x7fff8e3f9000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fac09f4b000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fac09ba7000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fac0a14f000)
/tools/bin/ld.bfd
linux-vdso.so.1 (0x7ffd797ca000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f4b398f)
libc.so.6 => /tools/lib/libc.so.6 (0x7f4b3954c000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f4b39af4000)
/tools/bin/nm
linux-vdso.so.1 (0x7fff3d4c3000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f6b9eeb5000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f6b9eb11000)
/tools/lib64/ld-linux-x86

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-17 Thread Read, James C 
>> I just checked again with a test build, I get the same results. All the
>> $LFS_TGT-* binaries do still link to /lib as they're the ones from the first
>> pass, so that should be nothing to worry about. Still, you are missing the
>> programs that should have been installed by Binutils Pass 2, so I would check
>> those commands very carefully against what's in the book, including verifying
>> that you did in fact remove the source and build directories between Pass 1
>> and Pass 2.

>Chris, I think you spotted the right issue: even the binutils executables
>prefixed with x86_64-unknown-linux-gnu- are not in James' /tools/bin. It looks
>like the "make install" step, before "make -C ld clean", was missed in
>binutils-pass2.

I've just rebuilt binutils. Here is my output of files created today:

ls -al /tools/bin/ | grep 'Dec 17'
drwxr-xr-x  2 lfs lfs12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root4096 Dec 17 13:05 ..
-rwxr-xr-x  1 lfs lfs  5307288 Dec 17 14:38 addr2line
-rwxr-xr-x  2 lfs lfs  5470840 Dec 17 14:38 ar
-rwxr-xr-x  2 lfs lfs  7456632 Dec 17 14:38 as
-rwxr-xr-x  1 lfs lfs  5265576 Dec 17 14:38 c++filt
-rwxr-xr-x  1 lfs lfs94576 Dec 17 14:38 elfedit
-rwxr-xr-x  1 lfs lfs  5829208 Dec 17 14:38 gprof
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld
-rwxr-xr-x  1 lfs lfs  7489760 Dec 17 13:22 ld-new
-rwxr-xr-x  4 lfs lfs  7489744 Dec 17 14:38 ld.bfd
-rwxr-xr-x  2 lfs lfs  5340912 Dec 17 14:38 nm
-rwxr-xr-x  2 lfs lfs  6284816 Dec 17 14:38 objcopy
-rwxr-xr-x  2 lfs lfs  7802816 Dec 17 14:38 objdump
-rwxr-xr-x  2 lfs lfs  5470832 Dec 17 14:38 ranlib
-rwxr-xr-x  1 lfs lfs  1287424 Dec 17 14:38 readelf
-rwxr-xr-x  1 lfs lfs  5296808 Dec 17 14:38 size
-rwxr-xr-x  1 lfs lfs  5296624 Dec 17 14:38 strings
-rwxr-xr-x  2 lfs lfs  6284840 Dec 17 14:38 strip
lfs@ubuntu:/mnt/lfs/sources/build$ ls -al /tools/lib/ | grep 'Dec 17'
drwxr-xr-x 10 lfs lfs 12288 Dec 17 14:38 .
drwxr-xr-x 13 lfs root 4096 Dec 17 13:05 ..
-rw-r--r--  1 lfs lfs  13939338 Dec 17 14:38 libbfd.a
-rwxr-xr-x  1 lfs lfs   882 Dec 17 14:38 libbfd.la
-rw-r--r--  1 lfs lfs   2537748 Dec 17 14:38 libopcodes.a
-rwxr-xr-x  1 lfs lfs   889 Dec 17 14:38 libopcodes.la

and if I've got this right here are the linked libraries

for F in /tools/bin/* ; do  modsecs=$(date --utc --reference=$F +%s); 
nowsecs=$(date +%s); delta=$(($nowsecs-$modsecs)); if [ $delta -lt 12000 ]; 
then echo $F; ldd $F; fi; done
/tools/bin/addr2line
linux-vdso.so.1 (0x7fffde7c6000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f1d420a1000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f1d41cfd000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f1d422a5000)
/tools/bin/ar
linux-vdso.so.1 (0x7fff8b7e3000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f574419)
libc.so.6 => /tools/lib/libc.so.6 (0x7f5743dec000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f5744394000)
/tools/bin/as
linux-vdso.so.1 (0x7ffdfcb8)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fa3a2132000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fa3a1d8e000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fa3a2336000)
/tools/bin/c++filt
linux-vdso.so.1 (0x7ffc73bb9000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fb0ca441000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fb0ca09d000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fb0ca645000)
/tools/bin/elfedit
linux-vdso.so.1 (0x7ffd595cf000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fbd87124000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fbd86d8)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fbd87328000)
/tools/bin/gprof
linux-vdso.so.1 (0x7ffd354cc000)
libm.so.6 => /tools/lib/libm.so.6 (0x7fcad0f1b000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fcad0d17000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fcad0973000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fcad1219000)
/tools/bin/ld
linux-vdso.so.1 (0x7ffdbad8d000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f3c4103b000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f3c40c97000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f3c4123f000)
/tools/bin/ld-new
linux-vdso.so.1 (0x7fff8e3f9000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fac09f4b000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fac09ba7000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fac0a14f000)
/tools/bin/ld.bfd
linux-vdso.so.1 (0x7ffd797ca000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f4b398f)
libc.so.6 => /tools/lib/libc.so.6 (0x7f4b3954c000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f4b39af4000)
/tools/bin/nm
linux-vdso.so.1 (0x7fff3d4c3000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7f6b9eeb5000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f6b9eb11000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f6

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Pierre Labastie 
On 15/12/2015 20:33, Chris Staub wrote:
> On 12/15/2015 01:57 PM, Chris Staub wrote:
>> On 12/15/2015 05:30 AM, Read, James C wrote:
>>>
>>>
>>> Output of  `for P in /tools/bin/* ; do echo $P ; ldd $P | grep '
>>> /lib/' ; done` shows that all infected programs have the prefix
>>> /lib/x86_64-linux* All of these utilities seem to be from binutils and
>>> gcc. I have no explanation for how this happened. I haven't logged out
>>> once and my environment, to this very moment is still exactly the same
>>> as it was when it was first set up. Env output already posted. Will
>>> post again further below for completeness.
>>>
>>>   for P in /tools/bin/* ; do
 echo $P ; ldd $P | grep ' /lib/' ; done
>>>
>>> Any other reasons this could have gone wrong?
>>>
>>> Daer Samej
>>>
>>>
>> Have you been removing every source and build directory after each
>> package installation? Forgetting to do this is the most likely cause of
>> this issue, especially since GCC and Binutils are the ones affected and
>> they're built twice in Chapter 5. Also, your output does not show
>> /tools/bin/ld, /tools/bin/ar, /tools/bin/as, or any of the other
>> binaries which should have been installed by Binutils Pass 2. I would go
>> back to Binutils and GCC instructions and check your command history for
>> both.
> 
> I just checked again with a test build, I get the same results. All the
> $LFS_TGT-* binaries do still link to /lib as they're the ones from the first
> pass, so that should be nothing to worry about. Still, you are missing the
> programs that should have been installed by Binutils Pass 2, so I would check
> those commands very carefully against what's in the book, including verifying
> that you did in fact remove the source and build directories between Pass 1
> and Pass 2.

Chris, I think you spotted the right issue: even the binutils executables
prefixed with x86_64-unknown-linux-gnu- are not in James' /tools/bin. It looks
like the "make install" step, before "make -C ld clean", was missed in
binutils-pass2.

Pierre
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Chris Staub 

On 12/15/2015 01:57 PM, Chris Staub wrote:

On 12/15/2015 05:30 AM, Read, James C wrote:



Output of  `for P in /tools/bin/* ; do echo $P ; ldd $P | grep '
/lib/' ; done` shows that all infected programs have the prefix
/lib/x86_64-linux* All of these utilities seem to be from binutils and
gcc. I have no explanation for how this happened. I haven't logged out
once and my environment, to this very moment is still exactly the same
as it was when it was first set up. Env output already posted. Will
post again further below for completeness.

  for P in /tools/bin/* ; do

echo $P ; ldd $P | grep ' /lib/' ; done


Any other reasons this could have gone wrong?

Daer Samej



Have you been removing every source and build directory after each
package installation? Forgetting to do this is the most likely cause of
this issue, especially since GCC and Binutils are the ones affected and
they're built twice in Chapter 5. Also, your output does not show
/tools/bin/ld, /tools/bin/ar, /tools/bin/as, or any of the other
binaries which should have been installed by Binutils Pass 2. I would go
back to Binutils and GCC instructions and check your command history for
both.


I just checked again with a test build, I get the same results. All the 
$LFS_TGT-* binaries do still link to /lib as they're the ones from the 
first pass, so that should be nothing to worry about. Still, you are 
missing the programs that should have been installed by Binutils Pass 2, 
so I would check those commands very carefully against what's in the 
book, including verifying that you did in fact remove the source and 
build directories between Pass 1 and Pass 2.

--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Vaughan Butler 
On 15 Dec 2015, at 18:43, Read, James C  wrote:

 are overwritten. So I guess there is nothing wrong with the binaries.
 What is wrong is with the libraries, like libanl, which are part of
 glibc (and others, which are built later). So I guess something went
 wrong during glibc build.
 One possibility is that '/bin/dash' is used instead of '/bin/bash'.
 Have you checked the link /bin/sh->/bin/bash?
 Another possibility is a typo in the configure line, or that
 $LFS_TGT was wrongly set at that point, or...
 
 Pierre
>>> 
>>> It should be that /bin/bash, not /bin/dash is the active shell.
>> Sorry if it was not clear: /bin/sh should be a symbolic link to
>> /bin/bash, not /bin/dash. If you use a debian-like system, the default
>> is to point to /bin/dash, and that causes issues (I am not able to find
>> a thread ATM).
> 
> No, this is definitely not the cause of the problem. /bin/sh was properly 
> linked all through out the build. 
> 
> Typo in the configuration line is also out of the question. I cut and paste 
> commands from the book. So if there is a type it is in the book.
> 
> Any other suggestions? Is it time to just place this build on the scrap heap 
> and start again from scratch? If so, what should I look out for on the next 
> build to make sure I don't run into the same kind of problem again?
> 
> In my experience copy and paste from the book (pdf) is asking for trouble, 
> while from the website is generally OK. Probably best to start again, 
> although not so bad if the source folder is intact. 
> -- 
> 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
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Chris Staub 

On 12/15/2015 05:30 AM, Read, James C wrote:



Output of  `for P in /tools/bin/* ; do echo $P ; ldd $P | grep ' /lib/' ; done` 
shows that all infected programs have the prefix /lib/x86_64-linux* All of 
these utilities seem to be from binutils and gcc. I have no explanation for how 
this happened. I haven't logged out once and my environment, to this very 
moment is still exactly the same as it was when it was first set up. Env output 
already posted. Will post again further below for completeness.

  for P in /tools/bin/* ; do

echo $P ; ldd $P | grep ' /lib/' ; done

/tools/bin/x86_64-lfs-linux-gnu-addr2line
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdbe65b8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fdbe61ee000)
/tools/bin/x86_64-lfs-linux-gnu-ar
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f50abdff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f50aba35000)
/tools/bin/x86_64-lfs-linux-gnu-as
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2ffbfae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2ffbbe4000)
/tools/bin/x86_64-lfs-linux-gnu-c++
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcd9713f000)
/tools/bin/x86_64-lfs-linux-gnu-c++filt
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8fa2c44000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8fa287a000)
/tools/bin/x86_64-lfs-linux-gnu-cpp
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff8bebd4000)
/tools/bin/x86_64-lfs-linux-gnu-elfedit
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9a68743000)
/tools/bin/x86_64-lfs-linux-gnu-g++
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd516c68000)
/tools/bin/x86_64-lfs-linux-gnu-gcc
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffbcead)
/tools/bin/x86_64-lfs-linux-gnu-gcc-5.2.0
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb86b5b6000)
/tools/bin/x86_64-lfs-linux-gnu-gcc-ar
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f861b376000)
/tools/bin/x86_64-lfs-linux-gnu-gcc-nm
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc19e427000)
/tools/bin/x86_64-lfs-linux-gnu-gcc-ranlib
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3a4308)
/tools/bin/x86_64-lfs-linux-gnu-gcov
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa36ec3f000)
/tools/bin/x86_64-lfs-linux-gnu-gcov-tool
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe7673e8000)
/tools/bin/x86_64-lfs-linux-gnu-gprof
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc105192000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc104dc8000)
/tools/bin/x86_64-lfs-linux-gnu-ld
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5bbc919000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5bbc54f000)
/tools/bin/x86_64-lfs-linux-gnu-ld.bfd
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f18407ae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f18403e4000)
/tools/bin/x86_64-lfs-linux-gnu-nm
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe78fe95000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe78facb000)
/tools/bin/x86_64-lfs-linux-gnu-objcopy
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8f7df75000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8f7dbab000)
/tools/bin/x86_64-lfs-linux-gnu-objdump
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2662eec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2662b22000)
/tools/bin/x86_64-lfs-linux-gnu-ranlib
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2388448000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f238807e000)
/tools/bin/x86_64-lfs-linux-gnu-readelf
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1ecc40d000)
/tools/bin/x86_64-lfs-linux-gnu-size
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3f7737a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3f76fb)
/tools/bin/x86_64-lfs-linux-gnu-strings
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f00bddde000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f00bda14000)
/tools/bin/x86_64-lfs-linux-gnu-strip
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7efcc046c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7efcc00a2000)


You should probably also run ldd on the .so libs in /tools/lib, in
case any of those link to /usr.


Any other reasons this could have gone wrong?

Daer Samej


Have you been removing every source and build directory after each 
package installation? Forgetting to do this is the most likely cause of 
this issue, especially since GCC and Binutils are the ones affected and 
they're built twice in Chapter 5. Also, your output does

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Read, James C 
>>> are overwritten. So I guess there is nothing wrong with the binaries.
>>> What is wrong is with the libraries, like libanl, which are part of
>>> glibc (and others, which are built later). So I guess something went
>>> wrong during glibc build.
>>> One possibility is that '/bin/dash' is used instead of '/bin/bash'.
>>> Have you checked the link /bin/sh->/bin/bash?
>>> Another possibility is a typo in the configure line, or that
>>> $LFS_TGT was wrongly set at that point, or...
>>>
>>> Pierre
>>
>> It should be that /bin/bash, not /bin/dash is the active shell.
>>
>>
>>
>Sorry if it was not clear: /bin/sh should be a symbolic link to
>/bin/bash, not /bin/dash. If you use a debian-like system, the default
>is to point to /bin/dash, and that causes issues (I am not able to find
>a thread ATM).

No, this is definitely not the cause of the problem. /bin/sh was properly 
linked all through out the build. 

Typo in the configuration line is also out of the question. I cut and paste 
commands from the book. So if there is a type it is in the book.

Any other suggestions? Is it time to just place this build on the scrap heap 
and start again from scratch? If so, what should I look out for on the next 
build to make sure I don't run into the same kind of problem again?

Daer Samej
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Pierre Labastie 

On 15/12/2015 14:40, Douglas R. Reno wrote:



On Dec 15, 2015 7:35 AM, "Pierre Labastie" > wrote:

>
> On 15/12/2015 11:38, Read, James C wrote:
>>>
>>> Here is my env:
>>> 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
>>
>> I just noticed. All the infected binaries have the prefix 
x86_64-lfs-linux-gnu which is exactly the value of $LFS_TGT in my env.

>>
>> What's the connection?
>>
> Normally, all binaries built during binutils-pass1 and gcc-pass1 
should link to the host libraries, so I guess there is nothing wrong 
here. Those binaries have the prefix x86_64-lfs-linux-gnu- and are 
hard-linked to the same names without the prefix. They are rebuilt 
during binutils-pass2 and gcc-pass2, but with the 
x86_64-unbknown-linux-gnu- prefix. They are also hard linked to the 
same names without the prefix, so that the previous non-prefixed files 
are overwritten. So I guess there is nothing wrong with the binaries. 
What is wrong is with the libraries, like libanl, which are part of 
glibc (and others, which are built later). So I guess something went 
wrong during glibc build.
> One possibility is that '/bin/dash' is used instead of '/bin/bash'. 
Have you checked the link /bin/sh->/bin/bash?
> Another possibility is a typo in the configure line, or that 
$LFS_TGT was wrongly set at that point, or...

>
> Pierre

It should be that /bin/bash, not /bin/dash is the active shell.



Sorry if it was not clear: /bin/sh should be a symbolic link to 
/bin/bash, not /bin/dash. If you use a debian-like system, the default 
is to point to /bin/dash, and that causes issues (I am not able to find 
a thread ATM).


Pierre
--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Douglas R. Reno 
On Dec 15, 2015 7:35 AM, "Pierre Labastie"  wrote:
>
> On 15/12/2015 11:38, Read, James C wrote:
>>>
>>> Here is my env:
>>> 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
>>
>> I just noticed. All the infected binaries have the prefix
x86_64-lfs-linux-gnu which is exactly the value of $LFS_TGT in my env.
>>
>> What's the connection?
>>
> Normally, all binaries built during binutils-pass1 and gcc-pass1 should
link to the host libraries, so I guess there is nothing wrong here. Those
binaries have the prefix x86_64-lfs-linux-gnu- and are hard-linked to the
same names without the prefix. They are rebuilt during binutils-pass2 and
gcc-pass2, but with the x86_64-unbknown-linux-gnu- prefix. They are also
hard linked to the same names without the prefix, so that the previous
non-prefixed files are overwritten. So I guess there is nothing wrong with
the binaries. What is wrong is with the libraries, like libanl, which are
part of glibc (and others, which are built later). So I guess something
went wrong during glibc build.
> One possibility is that '/bin/dash' is used instead of '/bin/bash'. Have
you checked the link /bin/sh->/bin/bash?
> Another possibility is a typo in the configure line, or that $LFS_TGT was
wrongly set at that point, or...
>
> Pierre

It should be that /bin/bash, not /bin/dash is the active shell.
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Pierre Labastie 

On 15/12/2015 11:38, Read, James C wrote:

Here is my env:
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

I just noticed. All the infected binaries have the prefix x86_64-lfs-linux-gnu 
which is exactly the value of $LFS_TGT in my env.

What's the connection?

Normally, all binaries built during binutils-pass1 and gcc-pass1 should 
link to the host libraries, so I guess there is nothing wrong here. 
Those binaries have the prefix x86_64-lfs-linux-gnu- and are hard-linked 
to the same names without the prefix. They are rebuilt during 
binutils-pass2 and gcc-pass2, but with the x86_64-unbknown-linux-gnu- 
prefix. They are also hard linked to the same names without the prefix, 
so that the previous non-prefixed files are overwritten. So I guess 
there is nothing wrong with the binaries. What is wrong is with the 
libraries, like libanl, which are part of glibc (and others, which are 
built later). So I guess something went wrong during glibc build.
One possibility is that '/bin/dash' is used instead of '/bin/bash'. Have 
you checked the link /bin/sh->/bin/bash?
Another possibility is a typo in the configure line, or that $LFS_TGT 
was wrongly set at that point, or...


Pierre

--
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Read, James C 

>Here is my env:

>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

I just noticed. All the infected binaries have the prefix x86_64-lfs-linux-gnu 
which is exactly the value of $LFS_TGT in my env.

What's the connection?

Daer Samej
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-15 Thread Read, James C 

>> >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.

I have no idea why not.

>> >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 =>  (0x7fff4971f000)
>>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd0cea3c000)
>>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd0ce672000)
 ^^^
>So at least one program in /tools/bin links to the host's libc.

Well spotted.

>>   /lib64/ld-linux-x86-64.so.2 (0x7fd0cec4)
>and it also uses the host's loader


>>>   linux-vdso.so.1 (0x7ffc4030d000)
>>>   libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8bf9f37000)
>>>   libc.so.6 => /tools/lib/libc.so.6 (0x7f8bf9b93000)
>>>   /tools/lib64/ld-linux-x86-64.so.2 (0x7f8bfa154000)

>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.

Output of  `for P in /tools/bin/* ; do echo $P ; ldd $P | grep ' /lib/' ; done` 
shows that all infected programs have the prefix /lib/x86_64-linux* All of 
these utilities seem to be from binutils and gcc. I have no explanation for how 
this happened. I haven't logged out once and my environment, to this very 
moment is still exactly the same as it was when it was first set up. Env output 
already posted. Will post again further below for completeness.

 for P in /tools/bin/* ; do
> echo $P ; ldd $P | grep ' /lib/' ; done
/tools/bin/[
/tools/bin/awk
/tools/bin/base64
/tools/bin/basename
/tools/bin/bash
/tools/bin/bashbug
/tools/bin/bunzip2
/tools/bin/bzcat
/tools/bin/bzcmp
/tools/bin/bzdiff
/tools/bin/bzegrep
/tools/bin/bzfgrep
/tools/bin/bzgrep
/tools/bin/bzip2
/tools/bin/bzip2recover
/tools/bin/bzless
/tools/bin/bzmore
/tools/bin/c++
/tools/bin/captoinfo
/tools/bin/cat
/tools/bin/catchsegv
/tools/bin/cc
/tools/bin/chcon
/tools/bin/checkmk
/tools/bin/chgrp
/tools/bin/chmod
/tools/bin/chown
/tools/bin/chroot
/tools/bin/cksum
/tools/bin/clear
/tools/bin/cmp
/tools/bin/comm
/tools/bin/cp
/tools/bin/cpp
/tools/bin/csplit
/tools/bin/cut
/tools/bin/date
/tools/bin/dd
/tools/bin/df
/tools/bin/diff
/tools/bin/diff3
/tools/bin/dir
/tools/bin/dircolors
/tools/bin/dirname
/tools/bin/du
/tools/bin/echo
/tools/bin/egrep
/tools/bin/env
/tools/bin/expand
/tools/bin/expect
/tools/bin/expr
/tools/bin/factor
/tools/bin/false
/tools/bin/fgrep
/tools/bin/file
/tools/bin/fmt
/tools/bin/fold
/tools/bin/g++
/tools/bin/gawk
/tools/bin/gawk-4.1.3
/tools/bin/gcc
/tools/bin/gcc-ar
/tools/bin/gcc-nm
/tools/bin/gcc-ranlib
/tools/bin/gcov
/tools/bin/gcov-tool
/tools/bin/gencat
/tools/bin/getconf
/tools/bin/getent
/tools/bin/grep
/tools/bin/groups
/tools/bin/gunzip
/tools/bin/gzexe
/tools/bin/gzip
/tools/bin/head
/tools/bin/hostid
/tools/bin/hostname
/tools/bin/iconv
/tools/bin/id
/tools/bin/igawk
/tools/bin/infocmp
/tools/bin/infotocap
/tools/bin/install
/tools/bin/join
/tools/bin/kill
/tools/bin/ld-new
/tools/bin/ldd
/tools/bin/link
/tools/bin/ln
/tools/bin/locale
/tools/bin/localedef
/tools/bin/logname
/tools/bin/ls
/tools/bin/m4
/tools/bin/make
/tools/bin/makedb
/tools/bin/md5sum
/tools/bin/mkdir
/tools/bin/mkfifo
/tools/bin/mknod
/tools/bin/mktemp
/tools/bin/msgfmt
/tools/bin/msgmerge
/tools/bin/mtrace
/tools/bi

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Ken Moffat 
On Mon, Dec 14, 2015 at 11:43:56PM +, 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 =>  (0x7fff4971f000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd0cea3c000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd0ce672000)
 ^^^
So at least one program in /tools/bin links to the host's libc.

>   /lib64/ld-linux-x86-64.so.2 (0x7fd0cec4)
and it also uses the host's loader

>   linux-vdso.so.1 (0x7ffc4030d000)
>   libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8bf9f37000)
>   libc.so.6 => /tools/lib/libc.so.6 (0x7f8bf9b93000)
>   /tools/lib64/ld-linux-x86-64.so.2 (0x7f8bfa154000)

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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Read, James C 

>> 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

>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

>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.

find /tools/bin/ -type f -perm /a+x -exec ldd {} \;   
linux-vdso.so.1 =>  (0x7fff4971f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd0cea3c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd0ce672000)
/lib64/ld-linux-x86-64.so.2 (0x7fd0cec4)
linux-vdso.so.1 (0x7ffc4030d000)
libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8bf9f37000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f8bf9b93000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f8bfa154000)
not a dynamic executable
linux-vdso.so.1 =>  (0x7ffd1cdc7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4e33fa8000)
/lib64/ld-linux-x86-64.so.2 (0x7f4e34372000)
not a dynamic executable
linux-vdso.so.1 (0x7ffde4ae8000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fca556e6000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fca55a8a000)
linux-vdso.so.1 (0x7ffdb63e4000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f3ef77c3000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f3ef7b67000)
linux-vdso.so.1 (0x7ffc587be000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f6604f82000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f6605326000)
linux-vdso.so.1 (0x7fffcffda000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fba94fd5000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fba95379000)
not a dynamic executable
linux-vdso.so.1 (0x7ffd178ce000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f5f98308000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f5f986ac000)
linux-vdso.so.1 =>  (0x7ffc381be000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc384cfe000)
/lib64/ld-linux-x86-64.so.2 (0x7fc3850c8000)
linux-vdso.so.1 (0x7fffd0bc4000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fd01000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fd0cd065000)
linux-vdso.so.1 (0x7fff92512000)
libm.so.6 => /tools/lib/libm.so.6 (0x7f0a29e54000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f0a29ab)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f0a2a152000)
linux-vdso.so.1 (0x7fff0c45d000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fa184815000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fa184bb9000)
linux-vdso.so.1 (0x7fff75d9d000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x7fe025149000)
libm.so.6 => /tools/lib/libm.so.6 (0x7fe024e4b000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fe024aa7000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fe02534d000)
linux-vdso.so.1 (0x7fff937d6000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f801738)
/tools/lib/ld-linux-x86-64.so.2 (0x7f8017724000)
not a dynamic executable
linux-vdso.so.1 (0x7ffe2b19a000)
libc.so.6 => /tools/lib/libc.so.6 (0x7fc1b1043000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7fc1b13e7000)
linux-vdso.so.1 (0x7ffdea728000)
libc.so.6 => /tools/lib/libc.so.6 (0x7f0b3cfd7000)
/tools/lib64/ld-linux-x86-64.so.2 (0x7f0b3d37b000)
linux-vdso.so.1 (0x7fffce94e000)
libncursesw.so.6 => /tools/lib/lib

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Ken Moffat 
On Mon, Dec 14, 2015 at 10:21:54PM +, 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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Read, James C 
>>
>> 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'

-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Pierre Labastie 
On 14/12/2015 21:11, Read, James C wrote:
> Been working through the book meticulously and had no real problems until
> building Perl in chapter 5.
> [...]
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_wait@GLIBC_PRIVATE'
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_init@GLIBC_PRIVATE'
> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
> `h_errno@GLIBC_PRIVATE'
> collect2: error: ld returned 1 exit status
> makefile:376: recipe for target 'perl' failed
> make: *** [perl] Error 1
> 
> 
> I can reproduce this error message in two words.
> 
> 
> 1) by copying verbatim the last compilation command:
> 
> 
> cc -o perl -fstack-protector-strong -L/usr/local/lib  perlmain.o
> lib/auto/B/B.a lib/auto/Compress/Raw/Bzip2/Bzip2.a
> lib/auto/Compress/Raw/Zlib/Zlib.a lib/auto/Cwd/Cwd.a
> lib/auto/Data/Dumper/Dumper.a lib/auto/Devel/PPPort/PPPort.a
> lib/auto/Devel/Peek/Peek.a lib/auto/Digest/MD5/MD5.a lib/auto/Digest/SHA/SHA.a
> lib/auto/Encode/Encode.a lib/auto/Fcntl/Fcntl.a
> lib/auto/File/DosGlob/DosGlob.a lib/auto/File/Glob/Glob.a
> lib/auto/Filter/Util/Call/Call.a lib/auto/Hash/Util/Util.a
> lib/auto/Hash/Util/FieldHash/FieldHash.a lib/auto/I18N/Langinfo/Langinfo.a
> lib/auto/IO/IO.a lib/auto/IPC/SysV/SysV.a lib/auto/List/Util/Util.a
> lib/auto/MIME/Base64/Base64.a lib/auto/Math/BigInt/FastCalc/FastCalc.a
> lib/auto/Opcode/Opcode.a lib/auto/POSIX/POSIX.a
> lib/auto/PerlIO/encoding/encoding.a lib/auto/PerlIO/mmap/mmap.a
> lib/auto/PerlIO/scalar/scalar.a lib/auto/PerlIO/via/via.a
> lib/auto/SDBM_File/SDBM_File.a lib/auto/Socket/Socket.a
> lib/auto/Storable/Storable.a lib/auto/Sys/Hostname/Hostname.a
> lib/auto/Sys/Syslog/Syslog.a lib/auto/Tie/Hash/NamedCapture/NamedCapture.a
> lib/auto/Time/HiRes/HiRes.a lib/auto/Time/Piece/Piece.a
> lib/auto/Unicode/Collate/Collate.a lib/auto/arybase/arybase.a
> lib/auto/attributes/attributes.a lib/auto/mro/mro.a lib/auto/re/re.a
> lib/auto/threads/threads.a lib/auto/threads/shared/shared.a
> lib/auto/Encode/Byte/Byte.a lib/auto/Encode/CN/CN.a
> lib/auto/Encode/EBCDIC/EBCDIC.a lib/auto/Encode/JP/JP.a
> lib/auto/Encode/KR/KR.a lib/auto/Encode/Symbol/Symbol.a
> lib/auto/Encode/TW/TW.a lib/auto/Encode/Unicode/Unicode.a libperl.a `cat
> ext.libs` -lm /tools/lib/libcrypt.a
> lib/auto/POSIX/POSIX.a(POSIX.o): In function `XS_POSIX_tmpnam':
> POSIX.c:(.text+0x3654): warning: the use of `tmpnam' is dangerous, better use
> `mkstemp'
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_wait@GLIBC_PRIVATE'
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_init@GLIBC_PRIVATE'
> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
> `h_errno@GLIBC_PRIVATE'
> collect2: error: ld returned 1 exit status
> 
> 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?)

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`.

But I am almost sure that this error should have occured before in coreutils...

> 
> 
> The configure command I gave for making binutils was copied directly from the 
> book
> 
> 
> CC=$LFS_TGT-gccAR=$LFS_TGT-ar
> RANLIB=$LFS_TGT-ranlib ../binutils-2.25.1/configure
> --prefix=/tools--disable-nls 
> --disable-werror   --with-lib-path=/tools/lib --with-sysroot
> &> ../buildlogs/secondpass/binutils-2.25.1/configurelog
> 
> 
> What could the problem be? Anyone seen anything like this before?
> 
>

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread Read, James C 

>> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
>> undefined reference to `__pthread_barrier_wait@GLIBC_PRIVATE'
>> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
>> undefined reference to `__pthread_barrier_init@GLIBC_PRIVATE'
>> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
>> `h_errno@GLIBC_PRIVATE'
>> collect2: error: ld returned 1 exit status
>> makefile:376: recipe for target 'perl' failed
>> make: *** [perl] Error 1

>Hello,

>Please review thread
>http://archive.linuxfromscratch.org/mail-archives/lfs-support/2015-March/048595.html

>See if anything in there can help you.

Already, read that thread before posting the question. OP later says:

This is the command. I double-checked,it matches with the book. Anyway, it
doesn't matter. As soon as you suggested it was a linker problem, I started
using my backup base LFS system which had no packages. I finished chapter 5
successfully and am going to start Chapter 6 now. I don't think this is
worth pursuing as we already know I must have made some mistake while
configuring binutils. Thank you for your time.

I don't have a backup base LFS system. I'm building this for the first time. I 
followed the instructions diligently. The thread you linked presents no 
relevant solution to the problem.

Thanks anyway,

Daer Samej
-- 
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

Re: [lfs-support] makefile:376: recipe for target 'perl' failed

2015-12-14 Thread William Harrington 
On Mon, December 14, 2015 20:11, Read, James C wrote:
> Been working through the book meticulously and had no real problems until
> building Perl in chapter 5.
>
>
> Here is the tail of the output:
>
>

> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_wait@GLIBC_PRIVATE'
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/librt.so:
> undefined reference to `__pthread_barrier_init@GLIBC_PRIVATE'
> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
> `h_errno@GLIBC_PRIVATE'
> collect2: error: ld returned 1 exit status
> makefile:376: recipe for target 'perl' failed
> make: *** [perl] Error 1

Hello,

Please review thread
http://archive.linuxfromscratch.org/mail-archives/lfs-support/2015-March/048595.html

See if anything in there can help you.

Sincerely,

William Harrington
-- 
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