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 wrote: > 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 > >> Enrique Larraia wrote: >> > 2014/1/22 Pierre M.R. >> > >> >> 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
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 wrote: > > Date: Fri, 17 Jan 2014 12:37:16 -0600 > > From: Louis Rine > > To: LFS Support List > > 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
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 wrote: > 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
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 wrote: > > 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
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 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
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 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
[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
