Hi, Thanks for the replies. First, yes, I removed directories gcc-4.8.1 and gcc-build before start building libstdc++-4.8.1, so this shouldn't be a problem... The 686-lfs-linux-gnu-ranlib file is there (together with many others) and is executable
lfs@tornasol:/mnt/lfs/tools/bin$ ls -l i686-lfs-linux-gnu-ranlib -rwxr-xr-x 2 root root 3420804 Jan 20 20:26 i686-lfs-linux-gnu-ranlib 2014/1/22 Ken Moffat <zarniwh...@ntlworld.com> > > > 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). > Mine too, the symlink to bash seems ok though: lfs@tornasol:/mnt/lfs/tools/bin$ file /bin/sh /bin/sh: symbolic link to `bash' My bash version is 4.2.25 as displayed: lfs@tornasol:/mnt/lfs/tools/bin$ /bin/sh --version GNU bash, version 4.2.25(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 > > > > 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. 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 ;-) > Sorry, but I think you need that drink :-( My libraries are in a slightly different location: lfs@tornasol:/mnt/lfs$ ldd $(type -pa i686-lfs-linux-gnu-ranlib) linux-gate.so.1 => (0xb7728000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76f9000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb754f000) /lib/ld-linux.so.2 (0xb7729000) I've checked, and the libraries are indeed there. Not surprisingly I have the same chunk of code in libtool script. These are the lines of the 'make' log file of Bruce, the first one is where I get the error, look at the second line: libtool: install: x86_64-lfs-linux-gnu-ranlib /tools/lib/../lib64/libsupc++.a libtool: finish: PATH="/tools/bin:/bin:/usr/bin:/sbin" ldconfig -n /tools/lib/../lib64 My shell PATH is set to PATH=/tools/bin:/bin:/usr/bin, but the second line above made me wonder, is there any chance that it is overwritten during the 'make install' call as Pierre M. R. suggests? Not sure how to check this. Ah! almost forgot, thanks for the explanation of the errors in the config.log, very instructive! kike
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
