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
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
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
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
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
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
