[lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Tom Blamer
I've been following the LFS 7.0 stable book exactly, as far as I know, but
I've hit a brick wall with building Bash in chapter 5.

For example, I see lots of messages like this in the output of make tests:

 ./glob.tests: command substitution: line 188: syntax error near
unexpected token `)'
 ./glob.tests: command substitution: line 188: `echo */man*/bash.*)'
 ./glob.tests: command substitution: line 190: syntax error near
unexpected token `)'
 ./glob.tests: command substitution: line 190: `echo */man*/bash.*)'

My host system is Fedora 16, x86_64.

There are at least four threads where other people had this problem or
something similar, and no one ever reported what the issue was. What's the
deal?
http://www.linuxfromscratch.org/pipermail/lfs-support/2009-September/036410.html
http://www.linuxfromscratch.org/pipermail/lfs-support/2010-January/037338.html
http://linuxfromscratch.org/pipermail/lfs-support/2011-November/041616.html
http://www.linuxfromscratch.org/pipermail/lfs-support/2010-February/037873.html
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Zhu Bicen
I also encounter this problem before,  I think the cause is on my build
machine, /bin/sh is pointing to dash, not bash.
please check this Pre Requirement.

/bin/sh should be a symbolic or hard link to bash


2011/12/4 Tom Blamer bla...@gmail.com

 I've been following the LFS 7.0 stable book exactly, as far as I know, but
 I've hit a brick wall with building Bash in chapter 5.

 For example, I see lots of messages like this in the output of make
 tests:

  ./glob.tests: command substitution: line 188: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 188: `echo */man*/bash.*)'
  ./glob.tests: command substitution: line 190: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 190: `echo */man*/bash.*)'

 My host system is Fedora 16, x86_64.

 There are at least four threads where other people had this problem or
 something similar, and no one ever reported what the issue was. What's the
 deal?

 http://www.linuxfromscratch.org/pipermail/lfs-support/2009-September/036410.html

 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-January/037338.html
 http://linuxfromscratch.org/pipermail/lfs-support/2011-November/041616.html

 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-February/037873.html


 --
 http://linuxfromscratch.org/mailman/listinfo/lfs-support
 FAQ: http://www.linuxfromscratch.org/lfs/faq.html
 Unsubscribe: See the above information page




-- 
Best Regards
Bicen Zhu
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Andrew Benton
On Sun, 4 Dec 2011 22:14:26 +0800
Zhu Bicen zhubi...@gmail.com wrote:

 I also encounter this problem before,  I think the cause is on my build
 machine, /bin/sh is pointing to dash, not bash.
 please check this Pre Requirement.

Is dash installed on Fedora? I thought it was a Debian thing.

Andy
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Andrew Benton
On Sun, 4 Dec 2011 04:49:05 -0600
Tom Blamer bla...@gmail.com wrote:

 I've been following the LFS 7.0 stable book exactly, as far as I know, but
 I've hit a brick wall with building Bash in chapter 5.
 
 For example, I see lots of messages like this in the output of make tests:
 
  ./glob.tests: command substitution: line 188: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 188: `echo */man*/bash.*)'
  ./glob.tests: command substitution: line 190: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 190: `echo */man*/bash.*)'
 
 My host system is Fedora 16, x86_64.
 
 There are at least four threads where other people had this problem or
 something similar, and no one ever reported what the issue was. What's the
 deal?
 http://www.linuxfromscratch.org/pipermail/lfs-support/2009-September/036410.html
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-January/037338.html
 http://linuxfromscratch.org/pipermail/lfs-support/2011-November/041616.html
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-February/037873.html

We don't know. No one who knows what they're doing has had that
problem. No one who's had the problem has ever worked out what went
wrong and posted an explanation. All we know is that something went
wrong.

Andy
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Bruce Dubbs
Tom Blamer wrote:
 I've been following the LFS 7.0 stable book exactly, as far as I know, but
 I've hit a brick wall with building Bash in chapter 5.
 
 For example, I see lots of messages like this in the output of make tests:
 
  ./glob.tests: command substitution: line 188: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 188: `echo */man*/bash.*)'
  ./glob.tests: command substitution: line 190: syntax error near
 unexpected token `)'
  ./glob.tests: command substitution: line 190: `echo */man*/bash.*)'
 
 My host system is Fedora 16, x86_64.
 
 There are at least four threads where other people had this problem or
 something similar, and no one ever reported what the issue was. What's the
 deal?
 http://www.linuxfromscratch.org/pipermail/lfs-support/2009-September/036410.html
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-January/037338.html
 http://linuxfromscratch.org/pipermail/lfs-support/2011-November/041616.html
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-February/037873.html

My first question is to ask what the output of the following is:

sh --version

Note that tests are not recommended in Chapter 5.   Read the note in 
section 4.6.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Tom Blamer
On Sun, Dec 4, 2011 at 12:39 PM, Bruce Dubbs bruce.du...@gmail.com wrote:

 Tom Blamer wrote:
  I've been following the LFS 7.0 stable book exactly, as far as I know,
 but
  I've hit a brick wall with building Bash in chapter 5.
 
  For example, I see lots of messages like this in the output of make
 tests:
 
   ./glob.tests: command substitution: line 188: syntax error near
  unexpected token `)'
   ./glob.tests: command substitution: line 188: `echo */man*/bash.*)'
   ./glob.tests: command substitution: line 190: syntax error near
  unexpected token `)'
   ./glob.tests: command substitution: line 190: `echo */man*/bash.*)'
 
  My host system is Fedora 16, x86_64.
 
  There are at least four threads where other people had this problem or
  something similar, and no one ever reported what the issue was. What's
 the
  deal?
 
 http://www.linuxfromscratch.org/pipermail/lfs-support/2009-September/036410.html
 
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-January/037338.html
 
 http://linuxfromscratch.org/pipermail/lfs-support/2011-November/041616.html
 
 http://www.linuxfromscratch.org/pipermail/lfs-support/2010-February/037873.html

 My first question is to ask what the output of the following is:

 sh --version

 Note that tests are not recommended in Chapter 5.   Read the note in
 section 4.6.

   -- Bruce
 --
 http://linuxfromscratch.org/mailman/listinfo/lfs-support
 FAQ: http://www.linuxfromscratch.org/lfs/faq.html
 Unsubscribe: See the above information page


This is actually my second attempt going through this, the first time I hit
similar bash errors in chapter 6 building glibc. So, after I started over,
I ran the bash tests here in chapter 5 to see if I was still broken.

[twblamer@localhost ~]$ lsb_release -a
LSB Version::core-4.0-amd64:core-4.0-noarch
Distributor ID: Fedora
Description:Fedora release 16 (Verne)
Release:16
Codename:   Verne
[twblamer@localhost ~]$ uname -r
3.1.2-1.fc16.x86_64
[twblamer@localhost ~]$ /bin/sh --version
GNU bash, version 4.2.20(1)-release (x86_64-redhat-linux-gnu)
[twblamer@localhost ~]$ sh --version
GNU bash, version 4.2.20(1)-release (x86_64-redhat-linux-gnu)

su --login lfs

lfs:~$ sh --version
GNU bash, version 4.2.20(1)-release (x86_64-redhat-linux-gnu) # -- still
pulling from host
lfs:~$ which sh
/bin/sh
lfs:~$ bash --version
GNU bash, version 4.2.10(2)-release (x86_64-unknown-linux-gnu)
lfs:~$ which bash
/tools/bin/bash

My stab in the dark is that this could have something to do with yacc. My
first attempt on this host system, the bash build broke because I didn't
have a yacc binary in my PATH. I installed the Fedora 16 byacc package and
that gave me a yacc binary. Someone else said that installing bison fixed
this problem for them, but I installed that first and it didn't help. On
Fedora 16, installing bison gives me some yacc-related header files, but no
yacc binary, hence why I had to install byacc.

Also, even if I'm pulling the wrong /bin/sh during the build, how would
that break the finished binary of bash? It seems like a parser problem
within the bash source (induced by environment, header files or whatever).

lfs:~$ yacc -V
yacc - 1.9 20101229
lfs:~$ which yacc
/usr/bin/yacc
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] LFS 7.0 - broken bash build - command substitution: syntax error near unexpected token `)'

2011-12-04 Thread Bruce Dubbs
Tom Blamer wrote:

 This is actually my second attempt going through this, the first time I hit
 similar bash errors in chapter 6 building glibc. So, after I started over,
 I ran the bash tests here in chapter 5 to see if I was still broken.

Yes, but you are running the tests with Fedora supporting programs.  I 
suggest just pressing on.  If you want, you can do a test build/test of 
bash first in Chapter 6.  At least then you have a known set of programs 
to work from.

   -- Bruce

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] 2nd Pass binutils install fails (LFS-dev)

2011-12-04 Thread str1chn1n3
Hello All,

It's unclear whether the email list is restricted to just the stable version-- 
if so, just say the word and I'll abandon DEV for STABLE.  If not, I could use 
a hand figuring out the cause of an install failure.

The details:
1) Building to a blank system, using Debian Live CD 
(debian-live-6.0.3-i386-rescue), which includes all necessary build tools.

2) As stated, I'm following LFS-DEV (SVN-20111201) to the letter with a couple 
minor deviations.

3) Deviations to the book are limited to:
Adding lfs user to sudoers file with 'ALL=(ALL)  NOPASSWD: ALL'.

Using indirect $SPECS file creation in _5.8. Adjusting the Toolchain_ by 
doing
$LFS_TGT-gcc -dumpspecs | sed \
-e 's@/lib\(64\)\?/ld@/tools@g' \
-e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  ./specs
sudo mv ./specs 
/mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.6.2
instead of the direct method
$LFS_TGT-gcc -dumpspecs | sed \
  -e 's@/lib\(64\)\?/ld@/tools@g' \
  -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  $SPECS
used in the book.

4) So far all steps have executed without a hitch, until reaching the install 
step of _5.9.1. Installation of Binutils_.  Then the following is reported:
  lfs@debian:/mnt/lfs/sources/binutils-build$ cat install.log
  make[1]: Entering directory `/mnt/lfs/sources/binutils-build'
  /bin/bash ../binutils-2.22/mkinstalldirs /tools /tools
  make[2]: Entering directory `/mnt/lfs/sources/binutils-build/bfd'
  make  install-recursive
  make[3]: Entering directory `/mnt/lfs/sources/binutils-build/bfd'
  Making install in doc
  make[4]: Entering directory `/mnt/lfs/sources/binutils-build/bfd/doc'
  test -z /tools/share/info || /bin/mkdir -p /tools/share/info
   /usr/bin/install -c -m 644 ../../../binutils-2.22/bfd/doc/bfd.info 
'/tools/share/info'
   install-info --info-dir='/tools/share/info' '/tools/share/info/bfd.info'
  This is not dpkg install-info anymore, but GNU install-info
  See the man page for ginstall-info for command line arguments
  make[4]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd/doc'
  Making install in po
  make[4]: Entering directory `/mnt/lfs/sources/binutils-build/bfd/po'
  make[4]: Nothing to be done for `install'.
  make[4]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd/po'
  make[4]: Entering directory `/mnt/lfs/sources/binutils-build/bfd'
  make[5]: Entering directory `/mnt/lfs/sources/binutils-build/bfd'
  make[5]: Nothing to be done for `install-exec-am'.
  test -z /tools/include || /bin/mkdir -p /tools/include
   /usr/bin/install -c -m 644 bfd.h 
../../binutils-2.22/bfd/../include/ansidecl.h 
../../binutils-2.22/bfd/../include/symcat.h 
../../binutils-2.22/bfd/../include/bfdlink.h '/tools/include'
  test -z /tools/lib || /bin/mkdir -p /tools/lib
   /bin/bash ./libtool   --mode=install /usr/bin/install -c   libbfd.la 
'/tools/lib'
  libtool: install: /usr/bin/install -c .libs/libbfd.lai /tools/lib/libbfd.la
  libtool: install: /usr/bin/install -c .libs/libbfd.a /tools/lib/libbfd.a
  libtool: install: chmod 644 /tools/lib/libbfd.a
  libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libbfd.a
  ./libtool: line 1118: i686-lfs-linux-gnu-ranlib: command not found
  make[5]: *** [install-bfdlibLTLIBRARIES] Error 127
  make[5]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd'
  make[4]: *** [install-am] Error 2
  make[4]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd'
  make[3]: *** [install-recursive] Error 1
  make[3]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd'
  make[2]: *** [install] Error 2
  make[2]: Leaving directory `/mnt/lfs/sources/binutils-build/bfd'
  make[1]: *** [install-bfd] Error 2
  make[1]: Leaving directory `/mnt/lfs/sources/binutils-build'
  make: *** [install] Error 
The relevant lines are:
  libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libbfd.a
  ./libtool: line 1118: i686-lfs-linux-gnu-ranlib: command not found

However, 'i686-lfs-linux-gnu-ranlib' exists and is executable:
  lfs@debian:/mnt/lfs/sources/binutils-build$ which i686-lfs-linux-gnu-ranlib
  /tools/bin/i686-lfs-linux-gnu-ranlib

  lfs@debian:/mnt/lfs/sources/binutils-build$ i686-lfs-linux-gnu-ranlib
  Usage: i686-lfs-linux-gnu-ranlib [options] archive
   Generate an index to speed access to archives
   The options are:
@file  Read options from file
-t   Update the archive's symbol map timestamp
-h --helpPrint this help message
-v --version Print version information
  i686-lfs-linux-gnu-ranlib: supported targets: elf32-i386 a.out-i386-linux 
pei-i386 elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
Checking /mnt/lfs/sources/binutils-build/bdf/libtool: line 1118 isn't too 
helpful as it is:
  ...
  # func_show_eval cmd [fail_exp]
  # Unless opt_silent is true, then output CMD.  Then, if opt_dryrun is
  # not 

Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

2011-12-04 Thread Chris Staub
On 12/05/2011 01:27 AM, str1chn1n3 wrote:
 Hello All,
 It's unclear whether the email list is restricted to just the stable
 version-- if so, just say the word and I'll abandon DEV for STABLE. If
 not, I could use a hand figuring out the cause of an install failure.
 The details:
 1) Building to a blank system, using Debian Live CD
 (debian-live-6.0.3-i386-rescue), which includes all necessary build tools.
 2) As stated, I'm following LFS-DEV (SVN-20111201) to the letter with a
 couple minor deviations.
 3) Deviations to the book are limited to:
 Adding lfs user to sudoers file with 'ALL=(ALL) NOPASSWD: ALL'.

If you are following the book, this is not necessary.

 Using indirect $SPECS file creation in _5.8. Adjusting the Toolchain_ by
 doing
 $LFS_TGT-gcc -dumpspecs | sed \
 -e 's@/lib\(64\)\?/ld@/tools@g' \
 -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  ./specs
 sudo mv ./specs /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.6.2

Mostly not a problem, but no need for sudo here.

 instead of the direct method
 $LFS_TGT-gcc -dumpspecs | sed \
 -e 's@/lib\(64\)\?/ld@/tools@g' \
 -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  $SPECS
 used in the book.
 4) So far all steps have executed without a hitch, until reaching the
 install step of _5.9.1. Installation of Binutils_. Then the following is
 reported:

 The relevant lines are:

 libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libbfd.a
 ./libtool: line 1118: i686-lfs-linux-gnu-ranlib: command not found

 which isn't apparent to me...
 /mnt/lfs/tools lists:

 -rwxr-xr-x 1 root root 3397 Dec 4 21:00 catchsegv*
 -rwxr-xr-x 1 root root 65419 Dec 4 20:59 gencat*
 -rwxr-xr-x 1 root root 41023 Dec 4 20:59 getconf*
 -rwxr-xr-x 1 root root 61553 Dec 4 21:00 getent*
 -rwxr-xr-x 1 root root 2899544 Dec 4 15:53 i686-lfs-linux-gnu-addr2line*
 -rwxr-xr-x 2 root root 3022263 Dec 4 15:53 i686-lfs-linux-gnu-ar*
 -rwxr-xr-x 2 root root 4299504 Dec 4 15:53 i686-lfs-linux-gnu-as*
 -rwxr-xr-x 1 root root 2860805 Dec 4 15:53 i686-lfs-linux-gnu-c++filt*
 -rwxr-xr-x 1 root root 686890 Dec 4 20:21 i686-lfs-linux-gnu-cpp*
 -rwxr-xr-x 1 root root 60396 Dec 4 15:53 i686-lfs-linux-gnu-elfedit*
 -rwxr-xr-x 2 root root 674867 Dec 4 20:21 i686-lfs-linux-gnu-gcc*
 -rwxr-xr-x 2 root root 674867 Dec 4 20:21 i686-lfs-linux-gnu-gcc-4.6.2*
 -rwxr-xr-x 1 root root 86749 Dec 4 20:21 i686-lfs-linux-gnu-gcov*
 -rwxr-xr-x 1 root root 3300225 Dec 4 15:53 i686-lfs-linux-gnu-gprof*
 -rwxr-xr-x 4 root root 4089777 Dec 4 15:53 i686-lfs-linux-gnu-ld*
 -rwxr-xr-x 4 root root 4089777 Dec 4 15:53 i686-lfs-linux-gnu-ld.bfd*
 -rwxr-xr-x 2 root root 2920079 Dec 4 15:53 i686-lfs-linux-gnu-nm*
 -rwxr-xr-x 2 root root 3443090 Dec 4 15:53 i686-lfs-linux-gnu-objcopy*
 -rwxr-xr-x 2 root root 4036461 Dec 4 15:53 i686-lfs-linux-gnu-objdump*
 -rwxr-xr-x 2 root root 3022258 Dec 4 15:53 i686-lfs-linux-gnu-ranlib*
 -rwxr-xr-x 1 root root 627697 Dec 4 15:53 i686-lfs-linux-gnu-readelf*
 -rwxr-xr-x 1 root root 2914676 Dec 4 15:53 i686-lfs-linux-gnu-size*
 -rwxr-xr-x 1 root root 2888697 Dec 4 15:53 i686-lfs-linux-gnu-strings*
 -rwxr-xr-x 2 root root 3443089 Dec 4 15:53 i686-lfs-linux-gnu-strip*
 -rwxr-xr-x 1 root root 199282 Dec 4 20:59 iconv*
 -rwxr-xr-x 1 root root 5788 Dec 4 21:00 ldd*
 -rwxr-xr-x 1 root root 16567 Dec 4 21:00 lddlibc4*
 -rwxr-xr-x 1 root root 99174 Dec 4 20:59 locale*
 -rwxr-xr-x 1 root root 976129 Dec 4 20:59 localedef*
 -rwxr-xr-x 1 root root 6485 Dec 4 20:59 mtrace*
 -rwxr-xr-x 1 root root 23718 Dec 4 21:00 pcprofiledump*
 -rwxr-xr-x 1 root root 217377 Dec 4 21:00 rpcgen*
 -rwxr-xr-x 1 root root 4265 Dec 4 21:00 sotruss*
 -rwxr-xr-x 1 root root 62867 Dec 4 21:00 sprof*
 -rwxr-xr-x 1 root root 7133 Dec 4 20:59 tzselect*
 -rwxr-xr-x 1 root root 5374 Dec 4 21:00 xtrace*

Looks like you've been installing stuff as the root user, which I 
suspect is the reason for adding the lfs user to sudoers. This is most 
likely the cause of your problems. rm -rf /tools/*, go back to the 
beginning of Chapter 5, and do the entire chapter as the lfs user, 
without using root until the book says to.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

2011-12-04 Thread str1chn1n3


--
From: Chris Staub ch...@beaker67.com
Sent: Monday, December 05, 2011 12:38 AM
To: LFS Support List lfs-support@linuxfromscratch.org
Subject: Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

 On 12/05/2011 01:27 AM, str1chn1n3 wrote:
 Hello All,
 It's unclear whether the email list is restricted to just the stable
 version-- if so, just say the word and I'll abandon DEV for STABLE. If
 not, I could use a hand figuring out the cause of an install failure.
 The details:
 1) Building to a blank system, using Debian Live CD
 (debian-live-6.0.3-i386-rescue), which includes all necessary build 
 tools.
 2) As stated, I'm following LFS-DEV (SVN-20111201) to the letter with a
 couple minor deviations.
 3) Deviations to the book are limited to:
 Adding lfs user to sudoers file with 'ALL=(ALL) NOPASSWD: ALL'.

 If you are following the book, this is not necessary.

 Using indirect $SPECS file creation in _5.8. Adjusting the Toolchain_ by
 doing
 $LFS_TGT-gcc -dumpspecs | sed \
 -e 's@/lib\(64\)\?/ld@/tools@g' \
 -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  ./specs
 sudo mv ./specs /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.6.2

 Mostly not a problem, but no need for sudo here.

 instead of the direct method
 $LFS_TGT-gcc -dumpspecs | sed \
 -e 's@/lib\(64\)\?/ld@/tools@g' \
 -e /^\*cpp:$/{n;s,$, -isystem /tools/include,}  $SPECS
 used in the book.
 4) So far all steps have executed without a hitch, until reaching the
 install step of _5.9.1. Installation of Binutils_. Then the following is
 reported:

 The relevant lines are:

 libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libbfd.a
 ./libtool: line 1118: i686-lfs-linux-gnu-ranlib: command not found

 which isn't apparent to me...
 /mnt/lfs/tools lists:

 -rwxr-xr-x 1 root root 3397 Dec 4 21:00 catchsegv*
 -rwxr-xr-x 1 root root 65419 Dec 4 20:59 gencat*
 -rwxr-xr-x 1 root root 41023 Dec 4 20:59 getconf*
 -rwxr-xr-x 1 root root 61553 Dec 4 21:00 getent*
 -rwxr-xr-x 1 root root 2899544 Dec 4 15:53 
 i686-lfs-linux-gnu-addr2line*
 -rwxr-xr-x 2 root root 3022263 Dec 4 15:53 i686-lfs-linux-gnu-ar*
 -rwxr-xr-x 2 root root 4299504 Dec 4 15:53 i686-lfs-linux-gnu-as*
 -rwxr-xr-x 1 root root 2860805 Dec 4 15:53 
 i686-lfs-linux-gnu-c++filt*
 -rwxr-xr-x 1 root root 686890 Dec 4 20:21 i686-lfs-linux-gnu-cpp*
 -rwxr-xr-x 1 root root 60396 Dec 4 15:53 i686-lfs-linux-gnu-elfedit*
 -rwxr-xr-x 2 root root 674867 Dec 4 20:21 i686-lfs-linux-gnu-gcc*
 -rwxr-xr-x 2 root root 674867 Dec 4 20:21 
 i686-lfs-linux-gnu-gcc-4.6.2*
 -rwxr-xr-x 1 root root 86749 Dec 4 20:21 i686-lfs-linux-gnu-gcov*
 -rwxr-xr-x 1 root root 3300225 Dec 4 15:53 i686-lfs-linux-gnu-gprof*
 -rwxr-xr-x 4 root root 4089777 Dec 4 15:53 i686-lfs-linux-gnu-ld*
 -rwxr-xr-x 4 root root 4089777 Dec 4 15:53 i686-lfs-linux-gnu-ld.bfd*
 -rwxr-xr-x 2 root root 2920079 Dec 4 15:53 i686-lfs-linux-gnu-nm*
 -rwxr-xr-x 2 root root 3443090 Dec 4 15:53 
 i686-lfs-linux-gnu-objcopy*
 -rwxr-xr-x 2 root root 4036461 Dec 4 15:53 
 i686-lfs-linux-gnu-objdump*
 -rwxr-xr-x 2 root root 3022258 Dec 4 15:53 i686-lfs-linux-gnu-ranlib*
 -rwxr-xr-x 1 root root 627697 Dec 4 15:53 i686-lfs-linux-gnu-readelf*
 -rwxr-xr-x 1 root root 2914676 Dec 4 15:53 i686-lfs-linux-gnu-size*
 -rwxr-xr-x 1 root root 2888697 Dec 4 15:53 
 i686-lfs-linux-gnu-strings*
 -rwxr-xr-x 2 root root 3443089 Dec 4 15:53 i686-lfs-linux-gnu-strip*
 -rwxr-xr-x 1 root root 199282 Dec 4 20:59 iconv*
 -rwxr-xr-x 1 root root 5788 Dec 4 21:00 ldd*
 -rwxr-xr-x 1 root root 16567 Dec 4 21:00 lddlibc4*
 -rwxr-xr-x 1 root root 99174 Dec 4 20:59 locale*
 -rwxr-xr-x 1 root root 976129 Dec 4 20:59 localedef*
 -rwxr-xr-x 1 root root 6485 Dec 4 20:59 mtrace*
 -rwxr-xr-x 1 root root 23718 Dec 4 21:00 pcprofiledump*
 -rwxr-xr-x 1 root root 217377 Dec 4 21:00 rpcgen*
 -rwxr-xr-x 1 root root 4265 Dec 4 21:00 sotruss*
 -rwxr-xr-x 1 root root 62867 Dec 4 21:00 sprof*
 -rwxr-xr-x 1 root root 7133 Dec 4 20:59 tzselect*
 -rwxr-xr-x 1 root root 5374 Dec 4 21:00 xtrace*

 Looks like you've been installing stuff as the root user, which I
 suspect is the reason for adding the lfs user to sudoers. This is most
 likely the cause of your problems. rm -rf /tools/*, go back to the
 beginning of Chapter 5, and do the entire chapter as the lfs user,
 without using root until the book says to.
 -- 
 http://linuxfromscratch.org/mailman/listinfo/lfs-support
 FAQ: http://www.linuxfromscratch.org/lfs/faq.html
 Unsubscribe: See the above information page


Whenever I attempt to install as user lfs sans sudo, I get 'Permission 
denied' for the target directory.  That's why lfs is sudoed.  Any thoughts 
why this might be happening?  (Btw, that's the reason for the indirect 
toolchain adjustment.)
 

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: 

Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

2011-12-04 Thread Chris Staub
 Whenever I attempt to install as user lfs sans sudo, I get 'Permission
 denied' for the target directory.  That's why lfs is sudoed.  Any thoughts
 why this might be happening?  (Btw, that's the reason for the indirect
 toolchain adjustment.)



That means you've missed something earlier in the book. Most likely, 
you've forgotten to chown $LFS/tools to the lfs user.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

2011-12-04 Thread str1chn1n3
I don;t think so, ownership was set to:
drwxr-xr-x 10 lfs  root  4096 Dec  4 21:00 tools/

I'll have to check the makeup of the default debian-live user used for the 
beginning root-based steps...
Anyways, bonking and remaking is no big deal all things considered.  I'll 
take your advice.  Thanks for the help.


--
From: Chris Staub ch...@beaker67.com
Sent: Monday, December 05, 2011 12:48 AM
To: LFS Support List lfs-support@linuxfromscratch.org
Subject: Re: [lfs-support] 2nd Pass binutils install fails (LFS-dev)

 Whenever I attempt to install as user lfs sans sudo, I get 'Permission
 denied' for the target directory.  That's why lfs is sudoed.  Any 
 thoughts
 why this might be happening?  (Btw, that's the reason for the indirect
 toolchain adjustment.)



 That means you've missed something earlier in the book. Most likely,
 you've forgotten to chown $LFS/tools to the lfs user.
 -- 
 http://linuxfromscratch.org/mailman/listinfo/lfs-support
 FAQ: http://www.linuxfromscratch.org/lfs/faq.html
 Unsubscribe: See the above information page
 
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page