Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Yep, 'sudo make install' turned out to be my problem, too. I'm not sure if I forgot to chown $LFS/tools or just used it out of habit, but either way doing it again and following the directions correctly fixed the problem for me. I didn't say anything because I also felt a little silly taking up people's time with that. But if this error crops up for someone else again, that's probably what caused it. On Thu, Jan 23, 2014 at 12:59 PM, Enrique Larraia elarr...@gmail.comwrote: Doh! In section 4.3 I overlooked the command: chown -v lfs $LFS/tools That's why I had to use 'sudo make install'' for $LFS/tools= /mnt/lfs/tools. I changed the owner of $LFS/tools to lfs user now. Sorry for wasting your time guys, but thanks anyway. kike 2014/1/22 Bruce Dubbs bruce.du...@gmail.com Enrique Larraia wrote: 2014/1/22 Pierre M.R. prousse...@sfr.fr Enrique Larraia wrote: Not sure how to check this. To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH Yeah, this solved the issue. Now I figured out what was going on. On adding echo $PATH at the beginning of the problematic function in libtools script it was revealed that PATH was set to a different value. The key is in running 'make install' as 'sudo make install'. From man You shouldn't be using sudo. You are installing into /tools as user lfs. -- Bruce -- 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Doh! In section 4.3 I overlooked the command: chown -v lfs $LFS/tools That's why I had to use 'sudo make install'' for $LFS/tools= /mnt/lfs/tools. I changed the owner of $LFS/tools to lfs user now. Sorry for wasting your time guys, but thanks anyway. kike 2014/1/22 Bruce Dubbs bruce.du...@gmail.com Enrique Larraia wrote: 2014/1/22 Pierre M.R. prousse...@sfr.fr Enrique Larraia wrote: Not sure how to check this. To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH Yeah, this solved the issue. Now I figured out what was going on. On adding echo $PATH at the beginning of the problematic function in libtools script it was revealed that PATH was set to a different value. The key is in running 'make install' as 'sudo make install'. From man You shouldn't be using sudo. You are installing into /tools as user lfs. -- Bruce -- 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
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 11:40:44AM +0100, Pierre M.R. wrote: Enrique Larraia wrote: libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found The error message comes from bash. It looks like 'make install' reset the shell PATH. I would suspect some security magics like selinux. Pierre If so, more likely AppArmor - but ubuntu has shipped with that for several years. ĸen -- 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
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
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 (0xe000)
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
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Enrique Larraia wrote: Not sure how to check this. To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
2014/1/22 Pierre M.R. prousse...@sfr.fr Enrique Larraia wrote: Not sure how to check this. To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH Yeah, this solved the issue. Now I figured out what was going on. On adding echo $PATH at the beginning of the problematic function in libtools script it was revealed that PATH was set to a different value. The key is in running 'make install' as 'sudo make install'. From man sudoers: Since environment variables can influence program behavior, sudoers provides a means to restrict which variables from the user's environment are inherited by the command to be run. There are two distinct ways sudoers can deal with environment variables. By default, the env_reset option is enabled. This causes commands to be executed with a minimal environment containing TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process permitted by the env_check and env_keep options. This is effectively a whitelist for environment variables. Thus, in theory PATH is kept in the environment, then I had a look at /etc/sudoers and found this option enbaled: Defaults secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin Which indeed matched the PATH value given in the libtool script. I commented it out, and 'sudo make install' went through. I guess sudo overwrites PATH if the option is enabled. Thank to all! Pierre -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Date: Wed, 22 Jan 2014 21:50:02 + From: lf...@cruziero.com (akhiezer) To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 Date: Fri, 17 Jan 2014 22:17:42 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 Louis, In case you've not already seen it: there may be a solution to the issue you're seeing: Enrique Larraia Wed Jan 22 21:47 Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture Seems that sudo settings were causing conflict. (( p.s. Although - and excuse the/any noise - OTTOMH am not sure why sudo need be part of the picture if the 'su - lfs' is done in '4.3. Adding the LFS User'. Also noticed earlier that the 'problematic' ranlib in your /tools/bin was owned by root:root ; which didn't seem right for that stage of build. BUT, am still not at a suitable environment for checking those out: hence again, apols for the/any noise. )) rgds, akh -- -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Wed, Jan 22, 2014 at 10:11:29PM +, akhiezer wrote: (( p.s. Although - and excuse the/any noise - OTTOMH am not sure why sudo need be part of the picture if the 'su - lfs' is done in '4.3. Adding the LFS User'. Also noticed earlier that the 'problematic' ranlib in your /tools/bin was owned by root:root ; which didn't seem right for that stage of build. BUT, am still not at a suitable environment for checking those out: hence again, apols for the/any noise. )) Well spotted - I had missed that ownership. Owning by root:root is probably, in itself, not a problem. But it appears to indicate that make install is being run as root. If that is the case, any errors can trash the host system. I don't, for the moment, understand *how* root came to be involved. ĸen -- 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
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Enrique Larraia wrote: 2014/1/22 Pierre M.R. prousse...@sfr.fr Enrique Larraia wrote: Not sure how to check this. To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH Yeah, this solved the issue. Now I figured out what was going on. On adding echo $PATH at the beginning of the problematic function in libtools script it was revealed that PATH was set to a different value. The key is in running 'make install' as 'sudo make install'. From man You shouldn't be using sudo. You are installing into /tools as user lfs. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Hi all,
I'm experiencing the same issue as Louis Rine in this thread:
https://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg21373.html
I'm unsure whether or not reply to the cited thread, or create one on my
own. I apologize if this causes a duplication of the same topic :(
I got the following otuput error after make install of package
libstdc++-4.8.1:
make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include'
Making install in libsupc++
make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++'
make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++'
test -z /tools/lib || /bin/mkdir -p /tools/lib
/bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la
'/tools/lib'
libtool: install: /usr/bin/install -c .libs/libsupc++.lai
/tools/lib/libsupc++.la
libtool: install: /usr/bin/install -c .libs/libsupc++.a
/tools/lib/libsupc++.a
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
make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127
make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++'
make: *** [install-recursive] Error 1
I've checked and i686-lfs-linux-gnu-gcc-ranlib IS under /tools/bin. I'm
building with host Ubuntu 12.04, I've checked the host requirements and are
all OK (i think), in particular:
- /bin/sh points to bash not dash
- /usr/bin/yacc - /etc/alternatives/yacc - /usr/bin/bison.yacc
with bison.yacc being the following simple script:
#! /bin/sh
exec '/usr/bin/bison' -y $@
.bashrc file of lfs user has $LFS variable well defined, /tools directory
is a symlink to $LFS/tools and $PATH has first /tools/bin.
In case you find it useful, I'm including the errors in the config.log
after configure Libstdc++-4.8.1, located in $LFS/sources/gcc-build. Not
sure what they mean or if they are related to the issue (yes, I untar'ed
gcc package again to build libstdc++):
lfs@tornasol:/mnt/lfs/sources/gcc-build$ cat config.log | grep -i error
i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-V'
i686-lfs-linux-gnu-gcc: fatal error: no input files
i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-qversion'
i686-lfs-linux-gnu-gcc: fatal error: no input files
i686-lfs-linux-gnu-g++: error: unrecognized command line option '-V'
i686-lfs-linux-gnu-g++: fatal error: no input files
i686-lfs-linux-gnu-g++: error: unrecognized command line option '-qversion'
i686-lfs-linux-gnu-g++: fatal error: no input files
conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory
conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory
collect2: error: ld returned 1 exit status
| /* Override any GCC internal prototype to avoid an error.
collect2: error: ld returned 1 exit status
| /* Override any GCC internal prototype to avoid an error.
collect2: error: ld returned 1 exit status
| /* Override any GCC internal prototype to avoid an error.
conftest.cpp:21:28: fatal error: ac_nonexistent.h: No such file or directory
conftest.cpp:21:28: fatal error: ac_nonexistent.h: No such file or directory
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
configure:15573:3: error: decimal floating point not supported for this
target
configure:15574:3: error: decimal floating point not supported for this
target
configure:15575:3: error: decimal floating point not supported for this
target
configure:15622:31: error: template argument 2 is invalid
configure:15622:54: error: expected '(' before 'i1'
configure:15622:54: error: expected ';' before 'i1'
configure:15623:36: error: template argument 2 is invalid
configure:15623:54: error: expected '(' before 'i2'
configure:15623:54: error: expected ';' before 'i2'
configure:15725: i686-lfs-linux-gnu-g++ -c -g -Werror -ffunction-sections
-fdata-sections conftest.cpp 5
configure:15882: i686-lfs-linux-gnu-gcc -c -Wimplicit-function-declaration
-Werror conftest.c 5
configure:15903: i686-lfs-linux-gnu-gcc -c -Wimplicit-function-declaration
-Werror conftest.c 5
configure:15929: i686-lfs-linux-gnu-gcc -c -Wimplicit-function-declaration
-Werror conftest.c 5
collect2: error: ld returned 1 exit status
| #define HAVE_STRERROR_L 1
| #define HAVE_STRERROR_R 1
| /* Override any GCC internal prototype to avoid an error.
configure:17362: checking for -Werror
conftest.cpp:67:38: error: size of array 'array' is negative
| #define HAVE_STRERROR_L 1
| #define HAVE_STRERROR_R 1
collect2: error: ld returned 1 exit status
| #define HAVE_STRERROR_L 1
| #define HAVE_STRERROR_R 1
conftest.c:99:23: fatal error: sys/filio.h: No such file or directory
| #define HAVE_STRERROR_L 1
| #define HAVE_STRERROR_R 1
conftest.c:66:23: fatal error:
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Tue, Jan 21, 2014 at 09:53:03PM +, Enrique Larraia wrote: Hi all, I'm experiencing the same issue as Louis Rine in this thread: https://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg21373.html I'm unsure whether or not reply to the cited thread, or create one on my own. I apologize if this causes a duplication of the same topic :( I think we are out of ideas on that thread, so either way will suit :-( I got the following otuput error after make install of package libstdc++-4.8.1: make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include' Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib || /bin/mkdir -p /tools/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/libsupc++.a 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 From memory, Louis was using x86_64 so the problem appears to be related to ubuntu-derived hosts, but on both architectures. What do 'ldd' and 'ls -l' report for /tools/bin/i686-lfs-linux-gnu-ranlib ? I'm expecting sensible results (all libraries present, and file is executable), but something unexpected is happening somewhere. make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I've checked and i686-lfs-linux-gnu-gcc-ranlib IS under /tools/bin. I'm building with host Ubuntu 12.04, I've checked the host requirements and are all OK (i think), in particular: - /bin/sh points to bash not dash - /usr/bin/yacc - /etc/alternatives/yacc - /usr/bin/bison.yacc with bison.yacc being the following simple script: #! /bin/sh exec '/usr/bin/bison' -y $@ .bashrc file of lfs user has $LFS variable well defined, /tools directory is a symlink to $LFS/tools and $PATH has first /tools/bin. I think we were hoping that if Louis started again with /bin/sh pointing to /bin/bash, it would fix it. That seemed a plausible hope, because the initial configure in the top level directory will use its shell and it converts variables which may then be used by configure scripts in other directories. Dash is known to be less powerful than bash and has often broken with constructs which work fine in bash. Oh well, something else must be involved. sigh/ In case you find it useful, I'm including the errors in the config.log after configure Libstdc++-4.8.1, located in $LFS/sources/gcc-build. Not sure what they mean or if they are related to the issue (yes, I untar'ed gcc package again to build libstdc++): Just to confirm : you removed the original gcc-4.8.1 and gcc-build directories before doing that ? lfs@tornasol:/mnt/lfs/sources/gcc-build$ cat config.log | grep -i error i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-V' i686-lfs-linux-gnu-gcc: fatal error: no input files i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-qversion' i686-lfs-linux-gnu-gcc: fatal error: no input files i686-lfs-linux-gnu-g++: error: unrecognized command line option '-V' i686-lfs-linux-gnu-g++: fatal error: no input files i686-lfs-linux-gnu-g++: error: unrecognized command line option '-qversion' i686-lfs-linux-gnu-g++: fatal error: no input files conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory collect2: error: ld returned 1 exit status | /* Override any GCC internal prototype to avoid an error. collect2: error: ld returned 1 exit status All these sorts of messages seem absolutely normal. Configure scripts are run by /bin/sh and most of them mainly do two things: (i.) generate program fragments and try to compile them - this determines if headers / libraries exist, or if certain things exist in certain functions: that is what you see above, and is all part of adapting the build to different systems (not just linux) or different architectures (ii.) they use pkg-config to find if a package exists, and how to compile against it. And then, at the end of configure, they use the settings to alter how Makefiles will be created. glibcxx_cv_system_error14=yes glibcxx_cv_system_error15=yes These sort of variables might be used in the creation of the various Makefiles ERROR_CONSTANTS_SRCDIR='config/os/generic' WERROR='' #define HAVE_STRERROR_L 1 #define HAVE_STRERROR_R 1 These sort of variables definitely get used in the creation of
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 12:23:26AM +, Ken Moffat wrote:
On Tue, Jan 21, 2014 at 09:53:03PM +, 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 (0xe000)
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
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Ken Moffat wrote:
On Wed, Jan 22, 2014 at 12:23:26AM +, Ken Moffat wrote:
On Tue, Jan 21, 2014 at 09:53:03PM +, 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 (0xe000)
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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Date: Thu, 16 Jan 2014 17:47:42 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 If this is the correct use of ldd... :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib linux-vdso.so.1 = (0x7fffa837b000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) Not sure how to tell if that output is correct... (Not near a machine with /tools -type stuff/logs in it just now.) I'm using netrunner 13.06 which is based on ubuntu 12 I think? In the host-sys-req output you gave below, the min/max version numbers all looked ok, at least outwith the following commented items. host system requirements check scripts gives the following :~$ ~/code/lfs/version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/dash At the time of present post, you have now of course, corrected that to be really bash and not dash. But see also note below re really starting build cleanly from scratch again. Binutils: (GNU Binutils for Ubuntu) 2.23.2 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc Is '/usr/bin/bison.yacc' just a short shell script? If so, can you post it here. . . gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 (Ubuntu EGLIBC 2.17-0ubuntu5.1) 2.17 NB that _says_ 'EGLIBC' and not specifically glibc (tho' dunno what exactly is in place). I'd expect there'd be likely some extra issues that you'd have to deal with if building on a (genuine) eglibc system and not a (genuine) glibc system. . . Which seemed ok, perhaps I missed something there after all? NB that once the host-sys-reqs are gotten to be all-ok, you're probably best (for the present issue) to start from scratch: I know you said that you had, after having corrected the 'dash' issue - but then in the same breath said you'd left stuff in /tools ; be sure to really be starting again from scratch - you're building the foundations at this stage, and you want them to be 'just-so'. rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Date: Fri, 17 Jan 2014 22:17:42 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 . . Anyway, as for those sanity checks: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib -rwxr-xr-x 2 root root 5204187 Jan 17 18:29 /tools/bin/x86_64-lfs-linux-gnu-ranlib* OK. Size looks very large, even re cross- stuff; not near a machine to check just now. $ /tools/bin/x86_64-lfs-linux-gnu-ranlib gives the usage message $ x86_64-lfs-linux-gnu-ranlib without path components still gives the usage message OK. $ whereis x86_64-lfs-linux-gnu-ranlib x86_64-lfs-linux-gnu-ranlib: so I guess whereis doesn't find it... $ which x86_64-lfs-linux-gnu-ranlib /tools/bin/x86_64-lfs-linux-gnu-ranlib but which seems to. Those look all-OK, incl the 'which' -vs- 'whereis' as they don't necessarily search in exactly the same set of places: if you did 'whereis -b -B /tools/bin -f x86_64-lfs-linux-gnu-ranlib ' then it should find it ok. I find it baffling. I can't understand why the install script for libstdc++ doesn't find that program. I *hope* I'm just making a simple typo somewhere, but I'm checking pretty darn closely and can't find one yet. Plus if I am making an error, I've made the same one several times in a row without being able to catch it. I'm wondering if something on my host system is too new of a version or something. See other reply today re perhaps some additional issues with/re host-sys-req. For the non-'problematic' items there, the max-version numbers look all-0K. rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Le 17/01/2014 19:37, Louis Rine a écrit : I ran the build again after fixing /bin/sh to be a link to /bin/bash. I formatted the lfs partition and re-downloaded the sources before running the build again, but it occurred to me after the fact that I didn't delete the lfs programs from /tools/bin. So maybe that was dumb. ??? /tools is a link to $LFS/tools. If you formatted the partition, you deleted all files. If you still have files in /tools/bin, it may indicate you did not set the link properly. See page 4.2 of the book. The second instruction on this page is really important. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Jan 17, 2014, at 12:43 PM, Douglas R. Reno wrote: I do not believe that the LFS Livecd works on any version over 7.0 Source: LFS LiveCD project homepage Douglas Reno If you want to use an updated lfs livecd for currenet LFS versions, then use this one. I do not upgrade it, anymore, as it took much work and distributions have better livecd's which a user can configure to meet the host system requirements. http://cross-lfs.org/~kb0iic/livecdupd/ Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Sat, Jan 18, 2014 at 01:28:58PM +, akhiezer wrote: Date: Fri, 17 Jan 2014 22:17:42 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 . . Anyway, as for those sanity checks: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib -rwxr-xr-x 2 root root 5204187 Jan 17 18:29 /tools/bin/x86_64-lfs-linux-gnu-ranlib* OK. Size looks very large, even re cross- stuff; not near a machine to check just now. Just a side-note that this size isn't totally out of order, I got 4.6M on x86_64-lfs-linux-gnu- on a gcc-4.8.1 host with CFLAGS unset and the file not stripped. ĸen -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
I ran the build again after fixing /bin/sh to be a link to /bin/bash. I formatted the lfs partition and re-downloaded the sources before running the build again, but it occurred to me after the fact that I didn't delete the lfs programs from /tools/bin. So maybe that was dumb. I did get the same error about x86_64_linux-gnu-ranlib, however. I guess the proper next step is to try to use the lfs livecd environment instead of my normal desktop. Before I do that I will probably try removing the installed programs and rebuilding again, but if it still runs up to the same error I dunno what else I could try short of switching to a known clean environment. Here's the host system requirements script that I ran before the most recent attempt, where the installation of Libstdc++-4.81 failed on make install with x86_64-lfs-linux-gnu-ranlib: command not found despite $PATH being /tools/bin:/bin:/usr/bin and /tools/bin containing x86-64-lfs-linux-gnu-ranlib. :~$ version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/bash Binutils: (GNU Binutils for Ubuntu) 2.23.2 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.20 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 4.0.1 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 (GNU libc) 2.18 grep (GNU grep) 2.14 gzip 1.5 Linux version 3.8.0-23-generic (buildd@batsu) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 m4 (GNU M4) 1.4.16 GNU Make 3.81 patch 2.6.1 Perl version='5.14.2'; GNU sed version 4.2.1 tar (GNU tar) 1.26 Texinfo: makeinfo (GNU texinfo) 4.13 xz (XZ Utils) 5.1.0alpha g++ compilation OK If I'm missing any obvious discrepancies, I apologize for bothering the mailing list. Since this problem is kind of weird and doesn't seem to have an immediate rational explanation, I was kind of hoping for some insights on why this might crop up, so I could fix it and add it as a little notch to my belt. :) I am still hoping that it is just caused by a simple error on my part, but I haven't been able to find one, yet. So yeah, if deleting the installed programs and rebuilding with fixed /bin/sh does not eliminate the error and no more useful data comes up, I'll just try the livecd. But I sure hope I get to find out what exactly is going wrong eventually... On Thu, Jan 16, 2014 at 8:32 PM, William Harrington kb0...@berzerkula.orgwrote: On Jan 16, 2014, at 5:56 PM, Louis Rine wrote: Ah, I was wondering if dash would make a difference. I will fix that and try again. Thank you. :) It does, and that is why the host system requirements states: Bash-3.2 (/bin/sh should be a symbolic or hard link to bash) But that may not be your only issue. I suggest you check the host system requirements. Sincerely, William Harrington -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
I do not believe that the LFS Livecd works on any version over 7.0 Source: LFS LiveCD project homepage Douglas Reno -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Oh, darn. I ought to have looked at that. Thank you for pointing that out. :) Hmm. On Fri, Jan 17, 2014 at 12:43 PM, Douglas R. Reno renodr2...@gmail.comwrote: I do not believe that the LFS Livecd works on any version over 7.0 Source: LFS LiveCD project homepage Douglas Reno -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Date: Fri, 17 Jan 2014 12:37:16 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 I ran the build again after fixing /bin/sh to be a link to /bin/bash. I formatted the lfs partition and re-downloaded the sources before running the build again, but it occurred to me after the fact that I didn't delete the lfs programs from /tools/bin. So maybe that was dumb. I did get the same error about x86_64_linux-gnu-ranlib, however. I guess the proper next step is to try to use the lfs livecd environment instead of my normal desktop. Before I do that I will probably try removing the installed programs and rebuilding again, but if it still runs up to the same error I dunno what else I could try short of switching to a known clean environment. Here's the host system requirements script that I ran before the most recent attempt, where the installation of Libstdc++-4.81 failed on make install with x86_64-lfs-linux-gnu-ranlib: command not found despite $PATH being /tools/bin:/bin:/usr/bin and /tools/bin containing x86-64-lfs-linux-gnu-ranlib. (It's noted that in the above you write the three variations: x86_64_linux-gnu-ranlib x86_64-lfs-linux-gnu-ranlib x86-64-lfs-linux-gnu-ranlib Given that, are you perhaps making simple typo(s) in yr build ? ) A few sanity-checks - try running the following: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib # Post the output here? $ /tools/bin/x86_64-lfs-linux-gnu-ranlib # Does it just should a usage/help message, or what? $ x86_64-lfs-linux-gnu-ranlib # NB no path components (incl not './') . # Does it just should a usage/help message, or what? $ whereis x86_64-lfs-linux-gnu-ranlib # Post the output here? $ which x86_64-lfs-linux-gnu-ranlib # Post the output here? Please don't top-post - it makes following the discussion unnecessarily difficult for folks. rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Yeah, I apologize for the typos there. I called in sick today and am a bit out of it. :t Anyway, as for those sanity checks: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib -rwxr-xr-x 2 root root 5204187 Jan 17 18:29 /tools/bin/x86_64-lfs-linux-gnu-ranlib* $ /tools/bin/x86_64-lfs-linux-gnu-ranlib gives the usage message $ x86_64-lfs-linux-gnu-ranlib without path components still gives the usage message $ whereis x86_64-lfs-linux-gnu-ranlib x86_64-lfs-linux-gnu-ranlib: so I guess whereis doesn't find it... $ which x86_64-lfs-linux-gnu-ranlib /tools/bin/x86_64-lfs-linux-gnu-ranlib but which seems to. I find it baffling. I can't understand why the install script for libstdc++ doesn't find that program. I *hope* I'm just making a simple typo somewhere, but I'm checking pretty darn closely and can't find one yet. Plus if I am making an error, I've made the same one several times in a row without being able to catch it. I'm wondering if something on my host system is too new of a version or something. On Fri, Jan 17, 2014 at 1:09 PM, akhiezer lf...@cruziero.com wrote: Date: Fri, 17 Jan 2014 12:37:16 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 I ran the build again after fixing /bin/sh to be a link to /bin/bash. I formatted the lfs partition and re-downloaded the sources before running the build again, but it occurred to me after the fact that I didn't delete the lfs programs from /tools/bin. So maybe that was dumb. I did get the same error about x86_64_linux-gnu-ranlib, however. I guess the proper next step is to try to use the lfs livecd environment instead of my normal desktop. Before I do that I will probably try removing the installed programs and rebuilding again, but if it still runs up to the same error I dunno what else I could try short of switching to a known clean environment. Here's the host system requirements script that I ran before the most recent attempt, where the installation of Libstdc++-4.81 failed on make install with x86_64-lfs-linux-gnu-ranlib: command not found despite $PATH being /tools/bin:/bin:/usr/bin and /tools/bin containing x86-64-lfs-linux-gnu-ranlib. (It's noted that in the above you write the three variations: x86_64_linux-gnu-ranlib x86_64-lfs-linux-gnu-ranlib x86-64-lfs-linux-gnu-ranlib Given that, are you perhaps making simple typo(s) in yr build ? ) A few sanity-checks - try running the following: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib # Post the output here? $ /tools/bin/x86_64-lfs-linux-gnu-ranlib # Does it just should a usage/help message, or what? $ x86_64-lfs-linux-gnu-ranlib # NB no path components (incl not './') . # Does it just should a usage/help message, or what? $ whereis x86_64-lfs-linux-gnu-ranlib # Post the output here? $ which x86_64-lfs-linux-gnu-ranlib # Post the output here? Please don't top-post - it makes following the discussion unnecessarily difficult for folks. rgds, akh -- -- 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
[lfs-support] 5.8 Libstdc++-4.8.1
Hello all. :) I'v gone through the book a couple times in the past on i686, but this is my first time around with x86_64. All seemed to go well until I ran into this little gem while installing libstdc++: ...lots of compilation output... Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib/../lib64 || /bin/mkdir -p /tools/lib/../lib64 /bin/bash ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib/../lib64' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/../lib64/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/../lib64/libsupc++.a libtool: install: chmod 644 /tools/lib/../lib64/libsupc++.a libtool: install: x86_64-lfs-linux-gnu-ranlib /tools/lib/../lib64/libsupc++.a *../libtool: line 1132: x86_64-lfs-linux-gnu-ranlib: command not found* make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I checked in /tools/bin, and indeed x86_64-lfs-linux-gnu-ranlib IS there, along with the other stuff that should be there. The lfs user environment seems to be all set up correctly, including $PATH which is /tools/bin:/bin:/usr/bin. I saw that another person on this list also had this error, but that discussion didn't seem to advance very far. I was able to compile the dummy program and get the correct response from the readelf ... | grep command after compiling glibc. During the configure, it had this stuff: checking whether ln -s works... yes checking for x86_64-lfs-linux-gnu-as... x86_64-lfs-linux-gnu-as checking for x86_64-lfs-linux-gnu-ar... x86_64-lfs-linux-gnu-ar *checking for x86_64-lfs-linux-gnu-ranlib... x86_64-lfs-linux-gnu-ranlib* checking whether to enable maintainer-specific portions of Makefiles... no configure: CPU config directory is cpu/i486 configure: OS config directory is os/gnu-linux checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by x86_64-lfs-linux-gnu-gcc... /mnt/lfs/tools/x86_64-lfs-linux-gnu/bin/ld and so forth, so it seems to be finding x86_64-lfs-linux-gnu-ranlib during the configure run, but not during the make install. I don't get it. If any of y'all gurus could suggest where my error might be, I'd be much obliged. After I had this problem the first time, I wiped the entire lfs partition, re-downloaded the source code, and ran build again up to this point, and got the same error, so it's clearly something specific, I just don't know what. Thanks for any help. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 04:23:51PM -0600, Louis Rine wrote: Hello all. :) I'v gone through the book a couple times in the past on i686, but this is my first time around with x86_64. All seemed to go well until I ran into this little gem while installing libstdc++: ...lots of compilation output... Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib/../lib64 || /bin/mkdir -p /tools/lib/../lib64 /bin/bash ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib/../lib64' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/../lib64/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/../lib64/libsupc++.a libtool: install: chmod 644 /tools/lib/../lib64/libsupc++.a libtool: install: x86_64-lfs-linux-gnu-ranlib /tools/lib/../lib64/libsupc++.a *../libtool: line 1132: x86_64-lfs-linux-gnu-ranlib: command not found* make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I checked in /tools/bin, and indeed x86_64-lfs-linux-gnu-ranlib IS there, along with the other stuff that should be there. The lfs user environment seems to be all set up correctly, including $PATH which is /tools/bin:/bin:/usr/bin. Perhaps /tools/bin/x86_64-lfs-linux-gnu-ranlib is broken. What does 'ldd' say about it ? What host system are you using, and did you check all the host system requirements ? ĸen -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
If this is the correct use of ldd... :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib linux-vdso.so.1 = (0x7fffa837b000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) Not sure how to tell if that output is correct... I'm using netrunner 13.06 which is based on ubuntu 12 I think? host system requirements check scripts gives the following :~$ ~/code/lfs/version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/dash Binutils: (GNU Binutils for Ubuntu) 2.23.2 bison (GNU Bison) 2.5 /usr/bin/yacc - /usr/bin/bison.yacc bzip2, Version 1.0.6, 6-Sept-2010. Coreutils: 8.20 diff (GNU diffutils) 3.2 find (GNU findutils) 4.4.2 GNU Awk 4.0.1 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 (Ubuntu EGLIBC 2.17-0ubuntu5.1) 2.17 grep (GNU grep) 2.14 gzip 1.5 Linux version 3.8.0-23-generic (buildd@batsu) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 m4 (GNU M4) 1.4.16 GNU Make 3.81 patch 2.6.1 Perl version='5.14.2'; GNU sed version 4.2.1 tar (GNU tar) 1.26 Texinfo: makeinfo (GNU texinfo) 4.13 xz (XZ Utils) 5.1.0alpha g++ compilation OK Which seemed ok, perhaps I missed something there after all? On Thu, Jan 16, 2014 at 5:23 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Thu, Jan 16, 2014 at 04:23:51PM -0600, Louis Rine wrote: Hello all. :) I'v gone through the book a couple times in the past on i686, but this is my first time around with x86_64. All seemed to go well until I ran into this little gem while installing libstdc++: ...lots of compilation output... Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib/../lib64 || /bin/mkdir -p /tools/lib/../lib64 /bin/bash ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib/../lib64' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/../lib64/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/../lib64/libsupc++.a libtool: install: chmod 644 /tools/lib/../lib64/libsupc++.a libtool: install: x86_64-lfs-linux-gnu-ranlib /tools/lib/../lib64/libsupc++.a *../libtool: line 1132: x86_64-lfs-linux-gnu-ranlib: command not found* make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I checked in /tools/bin, and indeed x86_64-lfs-linux-gnu-ranlib IS there, along with the other stuff that should be there. The lfs user environment seems to be all set up correctly, including $PATH which is /tools/bin:/bin:/usr/bin. Perhaps /tools/bin/x86_64-lfs-linux-gnu-ranlib is broken. What does 'ldd' say about it ? What host system are you using, and did you check all the host system requirements ? ĸen -- 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 05:47:42PM -0600, Louis Rine wrote: If this is the correct use of ldd... :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib linux-vdso.so.1 = (0x7fffa837b000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) Not sure how to tell if that output is correct... Looks ok : no such file can mean broken linkage, but not in this case. I'm using netrunner 13.06 which is based on ubuntu 12 I think? host system requirements check scripts gives the following :~$ ~/code/lfs/version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/dash Fix that - dash causes problems in all sorts of places. ĸen -- 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
Re: [lfs-support] 5.8 Libstdc++-4.8.1
Ah, I was wondering if dash would make a difference. I will fix that and try again. Thank you. :) On Thu, Jan 16, 2014 at 5:53 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Thu, Jan 16, 2014 at 05:47:42PM -0600, Louis Rine wrote: If this is the correct use of ldd... :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib linux-vdso.so.1 = (0x7fffa837b000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) Not sure how to tell if that output is correct... Looks ok : no such file can mean broken linkage, but not in this case. I'm using netrunner 13.06 which is based on ubuntu 12 I think? host system requirements check scripts gives the following :~$ ~/code/lfs/version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/dash Fix that - dash causes problems in all sorts of places. ĸen -- 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Jan 16, 2014, at 5:56 PM, Louis Rine wrote: Ah, I was wondering if dash would make a difference. I will fix that and try again. Thank you. :) It does, and that is why the host system requirements states: Bash-3.2 (/bin/sh should be a symbolic or hard link to bash) But that may not be your only issue. I suggest you check the host system requirements. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
