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. 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 ;-) -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
