Ken Moffat wrote:
> On Wed, Jan 22, 2014 at 12:23:26AM +0000, Ken Moffat wrote:
>> On Tue, Jan 21, 2014 at 09:53:03PM +0000, Enrique Larraia wrote:
>>
>>   Your error was
>>> libtool: install: chmod 644 /tools/lib/libsupc++.a
>>> libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a
>>> ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not
>>> found
>>
>
>   I got sufficiently interested by this to try building LFS-7.4 on my
> i686 7.4 system, using copy-and-paste.  Fortunately (although
> perhaps discouragingly for Enrique) this isn't very far into the
> build.
>
>>   That appears to be using a libtool script.  I don't recall if it is
>> within the gcc-build directory, or the gcc-4.8.1 source - or even in
>> a subdirectory.  But I guess it is in the top level of gcc-build (if
>> I'm wrong you'll need to search for it), and perhaps created from a
>> file in the gcc source by using sed on variables.
>>
>
>   OK, so I overlooked that we are now only trying to build and
> install in libstdc++.  The libtool script is gcc-build/libtool.
>>   What is the first line of this libtool script ?  (I'm guessing it
>> will be something like #!/bin/sh or #!/bin/bash ?
>
>   Mine starts #! /bin/sh so the /bin/sh symlink to /bin/bash is
> indeed important.  Let's try rechecking, in case something in
> ubuntu-land is making the symlink disappear (unlikely, but when the
> obvious fails, never discount things).
>
>   I get
> lfs:/mnt/lfs/sources/gcc-build$ file /bin/sh
> /bin/sh: symbolic link to `bash'
>
> lfs:/mnt/lfs/sources/gcc-build$ /bin/sh --version
> GNU bash, version 4.2.45(1)-release (i686-pc-linux-gnu)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
>   You are almost certainly using a different version of bash, please
> can you compare your results for those two commands ?
>
>   At this point, I'm expecting that the /bin/sh -> bash symlink is
> NOT effective - but that is guesswork, and I don't know why it would
> happen.

I don't know if it will help or not, but here is the log from my build 
this morning:

http://anduin.linuxfromscratch.org/~bdubbs/036-gcc-libstdc++-4.8.2

   -- Bruce




>   If your /bin/sh is any version of bash-4.2, please try what I've
> written below.
>>
>>   Can you paste the lines around line 1132 where it is invoking this
>> command ?  I'm not sure if the ranlib (i686-lfs-linux-gnu-ranlib) is
>> hard-coded in the libtool script [ i.e. something got processed by
>> the shell to create this libtool script ], or if it is using
>> variables.
>>
>
>   In fact, that is a chunk within a function which looks like this:
>
> # func_show_eval cmd [fail_exp]
> # Unless opt_silent is true, then output CMD.  Then, if opt_dryrun
> # is
> # not true, evaluate CMD.  If the evaluation of CMD fails, and
> # FAIL_EXP
> # is given, then evaluate it.
> func_show_eval ()
> {
>      my_cmd="$1"
>      my_fail_exp="${2-:}"
>
>      ${opt_silent-false} || {
>        func_quote_for_expand "$my_cmd"
>        eval "func_echo $func_quote_for_expand_result"
>      }
>
>      if ${opt_dry_run-false}; then :; else
>        eval "$my_cmd"
>        ^^^^^^^^^^^^^ this is line 1132
>        my_status=$?
>        if test "$my_status" -eq 0; then :; else
>          eval "(exit $my_status); $my_fail_exp"
>        fi
>      fi
> }
>
>   So we can see that either the function is being misparsed (perhaps
> the local variables give a problem), or else the command is simply
> not being found.
>
>   In the previous case (x86_64) I think we established that the
> ranlib WAS on the PATH, but let's check in your case that things are
> correct.  Here are my commands and results -
>
> lfs:/mnt/lfs/sources/gcc-build$ echo $PATH
> /tools/bin:/bin:/usr/bin
>
> lfs:/mnt/lfs/sources/gcc-build$ type -pa i686-lfs-linux-gnu-ranlib
> /tools/bin/i686-lfs-linux-gnu-ranlib
>
> lfs:/mnt/lfs/sources/gcc-build$ ldd $(type -pa
> i686-lfs-linux-gnu-ranlib)
>       linux-gate.so.1 (0xffffe000)
>       libz.so.1 => /lib/libz.so.1 (0xb7701000)
>       libc.so.6 => /lib/libc.so.6 (0xb754c000)
>       /lib/ld-linux.so.2 (0xb772d000)
>
>   And if your results really do match all of mine, I think I need a
> very stiff drink ;-)
>





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

Reply via email to