[lfs-support] SEARCH_DIR wrong / LFS 7.4 / 6.10. Adjusting the Toolchain / Ubuntu 12.04 LTS
Hi, In Adjusting the Toolchain, I found that the new linker is being used with the WRONG search paths. grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' ... prints nothing (and has no errors) instead of printing... SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); I found that my backup from the end of chapter 5 has ld-new = ld. -rwxr-xr-x 4 lfs lfs 4773993 Nov 21 22:43 ld -rwxr-xr-x 1 lfs lfs 4773993 Nov 21 22:43 ld-new ...in tools/bin/. They shouldn't be the same, right? I'd expect ld-new to differ from ld since section 5.9. Binutils-2.23.2 - Pass 2 where... make -C ld clean make -C ld LIB_PATH=/usr/lib:/lib cp -v ld/ld-new /tools/bin So maybe I missed that step. I can start from the beginning - again. But can I, perhaps restart from 5.9? -Ron Hartikka -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Adjusting the Toolchain - LFS 7.3
hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? Thank you for your attention and help! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Adjusting the Toolchain - LFS 7.3
hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? Thank you for your attention and 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] Adjusting the Toolchain - LFS 7.3
Em 11-05-2013 19:45, Mic Ky escreveu: hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? Thank you for your attention and help! I believe it is fine. searched the Errata but no mention of it. However, see discussion at: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg18615.html -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Adjusting the Toolchain - LFS 7.3
On Sun, May 12, 2013 at 05:49:55AM +0700, Mic Ky wrote: hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? Thank you for your attention and help! Probably, it is ok. But I have to question whether you are using LFS-7.3, or LFS-svn ? On my own builds of 7.3 (on x86_64) a reference to /tools was logged. With recent LFS-svn /tools no longer appears and the book has been changed to reflect that (I remember, because I had to change the test in my own buildscript). I don't recall the details of why the svn book was changed, so it is possible that the difference also exists on some 7.3 builds - but if it does, I haven't seen it on my own builds. I'd assumed it was soemthing to do with the move to either gcc-4.8 or the newer binutils. Either way, current LFS-svn is fine without /tools appearing in the SEARCH_DIRs, so even if your build really is 7.3 I don't think there will be a problem. I suggest you continue. ĸen -- das eine Mal als Tragödie, das andere 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] Adjusting the Toolchain - LFS 7.3
On May 11, 2013, at 6:07 PM, Ken Moffat wrote: don't recall the details of why the svn book was changed, so it is possible that the difference also exists on some 7.3 builds - but if it does, I haven't seen it on my own builds. I'd assumed it was soemthing to do with the move to either gcc-4.8 or the newer binutils. I think it because in svn we added sysroot to pass 2 of binutils. Which also fixes issues with check 0.9.9 with some multiarch hosts in ch5. 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] Adjusting the Toolchain - LFS 7.3
I use LFS 7.3 not LFS svn, on x86 (32-bit), so I can continue it. Thank you for your quick supports Mr. Ken and Mr. Fernando Date: Sun, 12 May 2013 00:07:47 +0100 From: zarniwh...@ntlworld.com To: lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] Adjusting the Toolchain - LFS 7.3 On Sun, May 12, 2013 at 05:49:55AM +0700, Mic Ky wrote: hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? Thank you for your attention and help! Probably, it is ok. But I have to question whether you are using LFS-7.3, or LFS-svn ? On my own builds of 7.3 (on x86_64) a reference to /tools was logged. With recent LFS-svn /tools no longer appears and the book has been changed to reflect that (I remember, because I had to change the test in my own buildscript). I don't recall the details of why the svn book was changed, so it is possible that the difference also exists on some 7.3 builds - but if it does, I haven't seen it on my own builds. I'd assumed it was soemthing to do with the move to either gcc-4.8 or the newer binutils. Either way, current LFS-svn is fine without /tools appearing in the SEARCH_DIRs, so even if your build really is 7.3 I don't think there will be a problem. I suggest you continue. ĸen -- das eine Mal als Tragödie, das andere 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] Adjusting the Toolchain - LFS 7.3
Mic Ky wrote: hello I got problem on Chapter 6.10. Adjusting the Toolchain - LFS 7.3 according to the LFS 7.3 book, the result of this command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' --- should be - SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); - but my result only 2 lines -- root:/# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); --- it is okay, or how to fix it? It's OK. We changed that about a month ago. I'll add it to the errata. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
adjusting the toolchain
Hello everyone, it's my first time to build the LFS. Now i have problem. I use LFS liveCD ,and the version is LFS6.3, make it in the VMware , When i first time adjusting the toolchain ,with this SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs gcc -dumpspecs $SPECFILE sed 's@^/lib/ld-linux.so.2@/tools@g' $SPECFILE tempspecfile mv -vf tempspecfile $SPECFILE unset SPECFILE The error information is bash: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/specs: Permission denied I have tried many times,and i do not know why . Can any one help me? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: adjusting the toolchain
On Mon, 15 Aug 2011 01:21:56 +0800
赵佳晖 jiahui.tar...@gmail.com wrote:
Hello
everyone, it's my first time to build the LFS. Now i have problem. I use
LFS liveCD ,and the version is LFS6.3, make it in the VMware , When i first
time adjusting the toolchain ,with this
SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs
gcc -dumpspecs $SPECFILE
sed 's@^/lib/ld-linux.so.2@/tools@g' $SPECFILE tempspecfile
mv -vf tempspecfile $SPECFILE
unset SPECFILE
The error information is bash: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/specs:
Permission denied
I have tried many times,and i do not know why . Can any one help me?
You should follow the book, install gcc into /tools and set /tools/bin
in your (or rather, the user lfs's ${PATH}). That way the first gcc in
your path will be the one in /tools/bin, not the one in /usr/bin on the
host system. Also, LFS-6.3 is old, don't waste your time. Get a copy of
the current version of LFS, 6.8.
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Where I must doing the 5.8. Adjusting the Toolchain?
5.7. Glibc-2.13 is done, the latest strings was: then echo 'stubs.h unchanged'; \ else /usr/bin/install -c -m 644 /mnt/lfs/sources/glibc-build/stubs.h /tools/include/gnu/stubs-32.h; fi rm -f /mnt/lfs/sources/glibc-build/stubs.h make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.13' I am feeling a little optimistic, and am afraid of be wrong in next steps. Where I must doing the 5.8. Adjusting the Toolchain? Into /mnt/lfs/sources? ---Fuf -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Where I must doing the 5.8. Adjusting the Toolchain?
On Thu, 24 Mar 2011 20:24:47 +0300 fuflono fufl...@aol.com wrote: Where I must doing the 5.8. Adjusting the Toolchain? Into /mnt/lfs/sources? It doesn't matter what directory you're in when you execute the commands on that page Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
6.10. Re-adjusting the Toolchain
Hi,
I don't quite understand how re-writing the 'specs' file under the '/tools'
directory actually works -- by the way it does work!.
The specs file that is written with the fancy 'sed' script shows up as:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/specs
I don't get how writing the spec file under directory '/tools' works?
The above spec file correctly has '/tools' removed leaving the correct
result behind: '/usr/lib'
However, if after running the fancy 'sed' command, I do
cc -dumpspecs | grep '/tools'
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386}
%{shared:-shared} %{!shared: %{!static:
%{rdynamic:-export-dynamic} %{m32:%{!dynamic-linker:-dynamic-linker
%{muclibc:%{mglibc:%e-mglibc and -muclibc used
together}/tools/lib/ld-uClibc.so.0;:/tools/lib/ld-linux.so.2}}}
%{!m32:%{!dynamic-linker:-dynamic-linker %{muclibc:%{mglibc:%e-mglibc and
-muclibc used
together}/tools/lib/ld64-uClibc.so.0;:/tools/lib64/ld-linux-x86-64.so.2
%{static:-static}}
Note that '/tools' is still there. Yet when I run the sanity check I still
get the correct result?
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
/usr/lib/crt1.o succeeded
/usr/lib/crti.o succeeded
/usr/lib/crtn.o succeeded
Just curious? I'm missing some small concept here?
Thanks,
John
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
Hi, from community reactions to subject mail I gather the problem (as usual) is in front my display. When starting my third round of LFS, I am going to use LFS 6.3 LiveCD as host system for LFS book 6-5 (-6?). Thank you. attachment: f_kuhlmann.vcf-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
v6.6 section 6.10, Re-adjusting the Toolchain
Hello,
I am having a problem getting thru section 6.10, Re-Adjusting the Toolchain.
The 3rd block of instructions seems to hang on the cc dummy.c... command. I
can ctrl-C, and it stops, but would like to know what may have caused it to not
complete, or if it is ok to continue.
From the Book, the 3rd block of commands are:
--
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
--
Here is the dummy.log file created:
--
Reading specs from /tools/lib/gcc/i686-pc-linux-gnu/4.4.3/specs
cc: unrecognized option '-v'
cc: unrecognized option '-mtune=generic'
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4.3/configure --prefix=/tools
--with-local-prefix=/tools --enable-clocale=gnu --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++
--disable-libstdcxx-pch --disable-multilib --disable-bootstrap
Thread model: posix
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
/tools/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1
--
I don't know if it is useful, but also attached is a log of the output each of
the prior commands in section 6.10.
Any help or direction to a solution would be appreciated.
Thank you.
David Gay
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_2
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: v6.6 section 6.10, Re-adjusting the Toolchain
From the Book, the 3rd block of commands are:
--
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
--
The only thing that I see that is different with your code and the
book's code is in the first line:
Yours
echo 'main(){}' dummy.c # no space '
Book's
echo 'main(){}' dummy.c # space '
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
On Mon, 2010-03-15 at 13:30 +0100, Franz L. Kuhlmann wrote: Trying to build LFS using the LiveCD.iso within SUN VirtualBox under Windows XP by the book echo $(gcc -print-libgcc-file-name) returns /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-/gnu/4.1.2 how come ??? While I am starting from scratch again (assuming I missed a turn somewhere) : Is there anybody around to give me a hint on what the problem might be? Why do you think there's a problem? Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: v6.6 section 6.10, Re-adjusting the Toolchain
Date: Tue, 16 Mar 2010 02:37:52 -0400
Subject: Re: v6.6 section 6.10, Re-adjusting the Toolchain
From: sto...@gmail.com
To: lfs-support@linuxfromscratch.org
From the Book, the 3rd block of commands are:
--
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
--
The only thing that I see that is different with your code and the
book's code is in the first line:
Yours
echo 'main(){}' dummy.c # no space '
Book's
echo 'main(){}' dummy.c # space '
--
Thanks for the quick response. However, I tried the above both with and
without the space, and still get the same issue. It's interesting that in my
email the space is missing, as I simply did a copy paste directly from the
book.
Looking at the dummy.log file, I wonder if the following line indicates that I
mistyped/did something in an earlier step:
cc: unrecognized option '-mtune=generic'
Any idea which step may have introduced this problem?
Thanks again for any help.
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_2
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
Trying to build LFS using the LiveCD.iso within SUN VirtualBox under Windows XP by the book echo $(gcc -print-libgcc-file-name) returns /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-/gnu/4.1.2 how come ??? While I am starting from scratch again (assuming I missed a turn somewhere) : Is there anybody around to give me a hint on what the problem might be? attachment: f_kuhlmann.vcf-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
2010/3/15 Franz L. Kuhlmann f_kuhlm...@freenet.de: Trying to build LFS using the LiveCD.iso within SUN VirtualBox under Windows XP by the book echo $(gcc -print-libgcc-file-name) returns /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-/gnu/4.1.2 how come ??? While I am starting from scratch again (assuming I missed a turn somewhere) : Is there anybody around to give me a hint on what the problem might be? Most of us have long since forgotten the details of the 6.3 book. And really, there doesn't seem to be any point in building a system with gcc-4.1.2 now. Beyond that, and assuming you are building on i686, that looks like a sensible place to create the specfile - what seems wrong ? ĸen -- After tragedy, and farce, OMG poneys! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
On 03/15/2010 08:30 AM, Franz L. Kuhlmann wrote: Trying to build LFS using the LiveCD.iso within SUN VirtualBox under Windows XP by the book echo $(gcc -print-libgcc-file-name) returns /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-/gnu/4.1.2 how come ??? While I am starting from scratch again (assuming I missed a turn somewhere) : Is there anybody around to give me a hint on what the problem might be? What problem? I believe that is exactly what the specfile location is supposed to look like. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-Book 6.3 Chap 5.7 Adjusting The Toolchain Error?
2010/3/15 Franz L. Kuhlmann f_kuhlm...@freenet.de: Trying to build LFS using the LiveCD.iso within SUN VirtualBox under Windows XP by the book echo $(gcc -print-libgcc-file-name) returns /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-/gnu/4.1.2 how come ??? While I am starting from scratch again (assuming I missed a turn somewhere) : Is there anybody around to give me a hint on what the problem might be? Read chapter 1.5 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re-adjusting the Toolchain (6.10)
Hi, I am trying to install lfs 6.5 and I started with a good toolbox of which I had made a backup. I rebuilt the environment, and made with success all the steps of Chapter 6 until 6.10. In this section the first steps are successful overcome but, when I give the command grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' there is no response. The book doesn't give any specification, but I gave all the 6.10 commands from the sources directory in the chroot jail. What's the mistake? By Louis -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
Hi,
I tried creating a Linux from Scratch using the latest stable version of the
online LFS-book. My host system is an Ubuntu 9.10 Karmic Koala.
So I arrived at chapter 5.8, adjusting the toolchain and all went ok until
there. Some minor errors here and there, but nothing lethal. I completely
followed the book up til now.
Creating the symbolic link seemed to go okay aswell:
l...@pluto:/mnt/lfs/sources$ SPECS=`dirname $($LFS_TGT-gcc
-print-libgcc-file-name)`/specs
l...@pluto:/mnt/lfs/sources$ $LFS_TGT-gcc -dumpspecs | sed
\
-e 's@/lib\(64\)\?/ld@/tools@g'
\
-e /^\*cpp:$/{n;s,$, -isystem /tools/include,}
$SPECS
l...@pluto:/mnt/lfs/sources$ echo New specs file is:
$SPECS
New specs file is:
/mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.4.1/specs
l...@pluto:/mnt/lfs/sources$ unset SPECS
I check the symbolic link, it seemed to have been altered correctly.
Then I tried the testing, which failed:
l...@pluto:/mnt/lfs/sources$ echo 'main(){}'
dummy.c
l...@pluto:/mnt/lfs/sources$ $LFS_TGT-gcc -B/tools/lib
dummy.c
/mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.4.1/../../../../i686-lfs-linux-gnu/bin/ld:
crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit
status
l...@pluto:/mnt/lfs/sources$ readelf -l a.out | grep ':
/tools'
readelf: Error: 'a.out': No such file
I tried to continue despite the errors, to see how grave they were.
Binutils could not make, as the book had suggested:
l...@pluto:/mnt/lfs/sources/binutils-build$ CC=$LFS_TGT-gcc -B/tools/lib/ \
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
../binutils-2.19.1/configure --prefix=/tools \
--disable-nls --with-lib-path=/tools/lib
checking build system type... i686-pc-linux-gnulibc1
checking host system type... i686-pc-linux-gnulibc1
checking target system type... i686-pc-linux-gnulibc1
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... i686-lfs-linux-gnu-gcc -B/tools/lib/
checking for C compiler default output file name... configure: error: in
`/mnt/lfs/sources/binutils-build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Checking the config.log didn't teach me a lot of new things. But the error
came before installing Binutils in second pass allready. Judging by the
error, I suppose it has to do with the C-compiler, so here's the Glibc make
and make install output from the shell:
l...@pluto:/mnt/lfs/sources/glibc-build$
make
(I omitted a part over here that didn't contain errors)
/bin/sh scripts/move-if-change
/mnt/lfs/sources/glibc-build/bits/stdio_lim.h.new
/mnt/lfs/sources/glibc-build/bits/stdio_lim.h
rm -f /mnt/lfs/sources/glibc-build/bits/stdio_lim.hT
/mnt/lfs/sources/glibc-build/bits/stdio_lim.dT
/mnt/lfs/sources/glibc-build/bits/stdio_lim.dt
touch /mnt/lfs/sources/glibc-build/bits/stdio_lim.st
mawk -f scripts/gen-sorted.awk
\
-v subdirs='csu assert ctype locale intl catgets math setjmp
signal stdlib stdio-common libio malloc string wcsmbs time dirent grp pwd
posix io termios resource misc socket sysvipc gmon gnulib iconv iconvdata
wctype manual shadow gshadow po argp crypt nss localedata timezone rt
conform debug dlfcn elf'
\
-v srcpfx=''
\
nptl/sysdeps/pthread/Subdirs sysdeps/unix/inet/Subdirs
sysdeps/unix/Subdirs assert/Depend intl/Depend catgets/Depend stdlib/Depend
stdio-common/Depend libio/Depend malloc/Depend string/Depend wcsmbs/Depend
time/Depend posix/Depend iconvdata/Depend nss/Depend localedata/Depend
rt/Depend debug/Depend
/mnt/lfs/sources/glibc-build/sysd-sorted-tmp
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed
(bad class -- [], [^] or
[)
/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near
]
mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, ,
subd
...
make[1]: Leaving directory
`/mnt/lfs/sources/glibc-2.10.1'
make[1]: Entering directory
`/mnt/lfs/sources/glibc-2.10.1'
mawk -f scripts/gen-sorted.awk
\
-v subdirs='csu assert ctype locale intl catgets math setjmp
signal stdlib stdio-common libio malloc string wcsmbs time dirent grp pwd
posix io termios resource misc socket sysvipc gmon gnulib iconv iconvdata
wctype manual shadow gshadow po argp crypt nss localedata timezone rt
conform debug dlfcn elf'
\
-v srcpfx=''
\
nptl/sysdeps/pthread/Subdirs sysdeps/unix/inet/Subdirs
sysdeps/unix/Subdirs assert/Depend intl/Depend catgets/Depend stdlib/Depend
stdio-common/Depend libio/Depend malloc/Depend string/Depend wcsmbs/Depend
time/Depend posix/Depend iconvdata/Depend nss/Depend localedata/Depend
rt/Depend debug/Depend
/mnt/lfs/sources/glibc-build/sysd-sorted-tmp
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed
(bad class -- [], [^] or
[)
/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near
]
mawk: scripts/gen-sorted.awk: line 19: runaway regular
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On Thu, Nov 5, 2009 at 2:28 PM, pieter blomme pieter.blo...@gmail.com wrote: Checking the config.log didn't teach me a lot of new things. But the error came before installing Binutils in second pass allready. Judging by the error, I suppose it has to do with the C-compiler, so here's the Glibc make and make install output from the shell: mawk -f scripts/gen-sorted.awk \ -v subdirs='csu assert ctype locale intl catgets math setjmp signal stdlib stdio-common libio malloc string wcsmbs time dirent grp pwd posix io termios resource misc socket sysvipc gmon gnulib iconv iconvdata wctype manual shadow gshadow po argp crypt nss localedata timezone rt conform debug dlfcn elf' The reason that Glibc can't compile is that you have Mawk on your system. Just run: sudo apt-get install gawk and try recompiling glibc. Oh, and what does version-check.sh output? -- William Immendorf The ultimate in free computing. -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On 11/05/2009 03:28 PM, pieter blomme wrote: Hi, I tried creating a Linux from Scratch using the latest stable version of the online LFS-book. My host system is an Ubuntu 9.10 Karmic Koala. So I arrived at chapter 5.8, adjusting the toolchain and all went ok until there. Some minor errors here and there, but nothing lethal. I completely followed the book up til now. Creating the symbolic link seemed to go okay aswell: `/mnt/lfs/sources/glibc-build/Versions.all', needed by `/mnt/lfs/sources/glibc-build/abi-versions.h'. Stop. make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.10.1' make: *** [install] Error 2 Not all that familiar with linux, just basic shell scripting, package installingen and experience with a couple of computer languages. This is my first real effort to modify the linux inner-system, so it might very well be that an error came along that I did not treat the way I should have treated. Thanks in advance, Pieter Aside from what William said about Gawk, you should not have continued past this. Apparently Glibc did not compile and did not install, so of course the toolchain adjustment failed. You can't just ignore an error and try to continue. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
This is wat version-check.sh outputs (after I installed gawk (again, I had already done once manually from the soundcloud database, but something might have gone wrong ofcourse)): bash, version 4.0.33(1)-release /bin/sh - /bin/dash Binutils: (GNU Binutils for Ubuntu) 2.20 bison (GNU Bison) 2.4.1 yacc not found bzip2, Version 1.0.5, 10-Dec-2007. Coreutils: 7.4 diff (GNU diffutils) 2.8.1 find (GNU findutils) 4.4.2 GNU Awk 3.1.6 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1 GNU C Library (EGLIBC) stable release version GNU grep 2.5.4 gzip 1.3.12 Linux version 2.6.31-14-386 (bui...@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 16:41:14 UTC 2009 m4 (GNU M4) 1.4.13 GNU Make 3.81 patch 2.5.9 Perl version='5.10.0'; GNU sed version 4.2.1 tar (GNU tar) 1.22 ./version-check.sh: line 32: makeinfo: command not found Compilation OK not sure what the missing yacc-problem is, since I downloaded yacc without much problems On Thu, Nov 5, 2009 at 9:32 PM, William Immendorf will.immend...@gmail.comwrote: On Thu, Nov 5, 2009 at 2:28 PM, pieter blomme pieter.blo...@gmail.com wrote: Checking the config.log didn't teach me a lot of new things. But the error came before installing Binutils in second pass allready. Judging by the error, I suppose it has to do with the C-compiler, so here's the Glibc make and make install output from the shell: mawk -f scripts/gen-sorted.awk \ -v subdirs='csu assert ctype locale intl catgets math setjmp signal stdlib stdio-common libio malloc string wcsmbs time dirent grp pwd posix io termios resource misc socket sysvipc gmon gnulib iconv iconvdata wctype manual shadow gshadow po argp crypt nss localedata timezone rt conform debug dlfcn elf' The reason that Glibc can't compile is that you have Mawk on your system. Just run: sudo apt-get install gawk and try recompiling glibc. Oh, and what does version-check.sh output? -- William Immendorf The ultimate in free computing. -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- Groeten, Pieter Frontal Noize Mailorder http://frontalnoize.blogspot.com - http://www.myspace.com/frontalnoizedistribution -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
pieter blomme wrote: This is wat version-check.sh outputs (after I installed gawk (again, I had already done once manually from the soundcloud database, but something might have gone wrong ofcourse)): bash, version 4.0.33(1)-release /bin/sh - /bin/dash First mistake. Change the symlink Binutils: (GNU Binutils for Ubuntu) 2.20 bison (GNU Bison) 2.4.1 yacc not found Second mistake. Create the symlink bzip2, Version 1.0.5, 10-Dec-2007. Coreutils: 7.4 diff (GNU diffutils) 2.8.1 find (GNU findutils) 4.4.2 GNU Awk 3.1.6 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1 GNU C Library (EGLIBC) stable release version GNU grep 2.5.4 gzip 1.3.12 Linux version 2.6.31-14-386 (bui...@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 16:41:14 UTC 2009 m4 (GNU M4) 1.4.13 GNU Make 3.81 patch 2.5.9 Perl version='5.10.0'; GNU sed version 4.2.1 tar (GNU tar) 1.22 ./version-check.sh: line 32: makeinfo: command not found Third mistake. sudo apt-get install texinfo Fourth mistake. Don't top post. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On 11/05/2009 03:54 PM, Bruce Dubbs wrote: pieter blomme wrote: This is wat version-check.sh outputs (after I installed gawk (again, I had already done once manually from the soundcloud database, but something might have gone wrong ofcourse)): bash, version 4.0.33(1)-release /bin/sh - /bin/dash First mistake. Change the symlink No need for that...long as /bin/bash is specified for the LFS user. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On Thu, Nov 5, 2009 at 10:05 PM, Chris Staub ch...@beaker67.com wrote: On 11/05/2009 03:54 PM, Bruce Dubbs wrote: pieter blomme wrote: This is wat version-check.sh outputs (after I installed gawk (again, I had already done once manually from the soundcloud database, but something might have gone wrong ofcourse)): bash, version 4.0.33(1)-release /bin/sh - /bin/dash First mistake. Change the symlink No need for that...long as /bin/bash is specified for the LFS user. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Sorry for top-posting, and for being an ignorant fool. Version-check currently looks like this: bash, version 4.0.33(1)-release /bin/sh - /bin/sh Binutils: (GNU Binutils for Ubuntu) 2.20 bison (GNU Bison) 2.4.1 /usr/bin/yacc - /usr/bin/yacc bzip2, Version 1.0.5, 10-Dec-2007. Coreutils: 7.4 diff (GNU diffutils) 2.8.1 find (GNU findutils) 4.4.2 GNU Awk 3.1.6 /usr/bin/awk - /usr/bin/gawk gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1 GNU C Library (EGLIBC) stable release version GNU grep 2.5.4 gzip 1.3.12 Linux version 2.6.31-14-386 (bui...@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 16:41:14 UTC 2009 m4 (GNU M4) 1.4.13 GNU Make 3.81 patch 2.5.9 Perl version='5.10.0'; GNU sed version 4.2.1 tar (GNU tar) 1.22 makeinfo (GNU texinfo) 4.13 Compilation OK There's no problem with the awk-link, is there? Will reformat the partition and try a second time. I learned something, so it was worth it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
pieter blomme wrote: Sorry for top-posting, and for being an ignorant fool. Version-check currently looks like this: bash, version 4.0.33(1)-release /bin/sh - /bin/sh This looks strange. It should be: /bin/sh - bash Alternatively it *could* be a hard link to bash, but that is not very common. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
Chris Staub wrote: On 11/05/2009 03:54 PM, Bruce Dubbs wrote: pieter blomme wrote: This is wat version-check.sh outputs (after I installed gawk (again, I had already done once manually from the soundcloud database, but something might have gone wrong ofcourse)): bash, version 4.0.33(1)-release /bin/sh - /bin/dash First mistake. Change the symlink No need for that...long as /bin/bash is specified for the LFS user. I'm not sure about that Chris. That means that no script will ever invoke sh. IIRC, glibc is especailly bad about having bashisms in sh scripts. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On Thu, Nov 5, 2009 at 10:29 PM, Bruce Dubbs bruce.du...@gmail.com wrote: pieter blomme wrote: Sorry for top-posting, and for being an ignorant fool. Version-check currently looks like this: bash, version 4.0.33(1)-release /bin/sh - /bin/sh This looks strange. It should be: /bin/sh - bash Alternatively it *could* be a hard link to bash, but that is not very common. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page I hard-linked it via an executable-command. -- Groeten, Pieter Frontal Noize Mailorder http://frontalnoize.blogspot.com - http://www.myspace.com/frontalnoizedistribution -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
On 11/05/2009 04:24 PM, Bruce Dubbs wrote: Chris Staub wrote: On 11/05/2009 03:54 PM, Bruce Dubbs wrote: First mistake. Change the symlink No need for that...long as /bin/bash is specified for the LFS user. I'm not sure about that Chris. That means that no script will ever invoke sh. IIRC, glibc is especailly bad about having bashisms in sh scripts. I have built LFS using /bin/sh - dash (and /usr/bin/awk - mawk) recently with no problems. I know Glibc has had problems before with using bashisms but not specifying Bash, but that has been fixed. Don't really know what you mean by no script will ever invoke sh. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error at 5.8 Adjusting the Toolchain (Last stable version of the book)
Chris Staub wrote: On 11/05/2009 04:24 PM, Bruce Dubbs wrote: Chris Staub wrote: On 11/05/2009 03:54 PM, Bruce Dubbs wrote: First mistake. Change the symlink No need for that...long as /bin/bash is specified for the LFS user. I'm not sure about that Chris. That means that no script will ever invoke sh. IIRC, glibc is especailly bad about having bashisms in sh scripts. I have built LFS using /bin/sh - dash (and /usr/bin/awk - mawk) recently with no problems. I know Glibc has had problems before with using bashisms but not specifying Bash, but that has been fixed. Don't really know what you mean by no script will ever invoke sh. Interesting. That is a recent change then because it has caused problems in the past. I still think that bash/awk are known to be good. Others may cause problems or may work. It may even depend on the package versions. Sometimes scripts will invoke subscripts with '/bin/sh script'. Whether that will work with dash depends on the script. We know the book's instructions work with bash. I really don't want to get into the business of checking the book's instructions with multiple versions of host tools. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
Hi all, I'm fairly new to LFS and enjoying the build so far. I've made it to 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807 When I ran the command below: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' it returned the following: SEARCH_DIR(/tools/x86_64- unknown-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(lib); So, I'm missing the / before lib on the last line. I went back through the manual to see where I might have made a mistake. In 5.12. Binutils-2.17 - Pass 2, there is the following line: make -C ld LIB_PATH=/usr/lib:/lib Is it possible that my mistake was leaving out the / before the lib at the end of the line? Does anyone have any suggestions for how to fix the / I'm missing in SEARCH_DIR(lib); ? Thanks, William -- If you're always breaking up your routine and you want to break up your routine, do you do the same thing? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
On Sun, May 3, 2009 at 9:53 AM, William Stevenson w...@alumni.princeton.edu wrote: I'm fairly new to LFS and enjoying the build so far. I've made it to 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807 WTH?!?!?! You are using a obslete x86_64 book, and a old one at it too. If you want a good x86_64 system from scratch, you might wanna try Cross LFS, at cross-lfs.org. (BTW, x86_64 support in LFS is currently expermental.) William -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
William, I built my own box and have an Athalon processor with 4GB RAM, so I'd like to be able to address the full 4GB. I didn't think I could do this with a 32 bit operating system. Also, when I went to download the LiveCD, this is the manual that came with the most recent download from the mirror for the x86_64 (lfslivecd-x86_64-6.3-r2160.iso ), I thought for my first build I should start with an LFS book rather than an CLFS one? But, point taken, I'll look into CLFS. That said, I seemed to pass the Glibc test. There was only one extra error and it was similar to the other nptl ones mentioned. If anyone has any thoughts, I'd like to keep going if possible. Thanks, William On Sun, May 3, 2009 at 10:56 AM, William Immendorf will.immend...@gmail.com wrote: On Sun, May 3, 2009 at 9:53 AM, William Stevenson w...@alumni.princeton.edu wrote: I'm fairly new to LFS and enjoying the build so far. I've made it to 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807 WTH?!?!?! You are using a obslete x86_64 book, and a old one at it too. If you want a good x86_64 system from scratch, you might wanna try Cross LFS, at cross-lfs.org. (BTW, x86_64 support in LFS is currently expermental.) William -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- If you're always breaking up your routine and you want to break up your routine, do you do the same thing? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
On Sun, May 3, 2009 at 10:23 AM, William Stevenson w...@alumni.princeton.edu wrote: That said, I seemed to pass the Glibc test. There was only one extra error and it was similar to the other nptl ones mentioned. If anyone has any thoughts, I'd like to keep going if possible. Uh... you should switch to CLFS immediately to build this system, becuase, the book you are using, does not have a bootloader, among other things. William -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
Uh... you should switch to CLFS immediately to build this system, becuase, the book you are using, does not have a bootloader, among other things. got it, thanks - will do On Sun, May 3, 2009 at 11:38 AM, William Immendorf will.immend...@gmail.com wrote: On Sun, May 3, 2009 at 10:23 AM, William Stevenson w...@alumni.princeton.edu wrote: That said, I seemed to pass the Glibc test. There was only one extra error and it was similar to the other nptl ones mentioned. If anyone has any thoughts, I'd like to keep going if possible. Uh... you should switch to CLFS immediately to build this system, becuase, the book you are using, does not have a bootloader, among other things. William -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- If you're always breaking up your routine and you want to break up your routine, do you do the same thing? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
On Sunday 03 May 2009 10:56:22 William Immendorf wrote: You are using a obslete x86_64 book, and a old one at it too. This is wrong! It should be: ... an obslete ... an old ... -- http://www.wowgreen.net/11324 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
On Sun, May 3, 2009 at 12:22 PM, genericmailli...@gmail.com wrote: This is wrong! It should be: ... an obslete ... an old ... What I meant by obslete, is that it isn't used anymore. William -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SEARCH_DIR(lib); missing / in 6.10 Adjusting the toolchain in Version SVN-x86_64-20070807
On Sun, May 03, 2009 at 12:40:38PM -0500, William Immendorf wrote: On Sun, May 3, 2009 at 12:22 PM, genericmailli...@gmail.com wrote: This is wrong! It should be: ... an obslete ... an old ... What I meant by obslete, is that it isn't used anymore. William I think he was correcting your English; you had written 'a obslete' and it should have been 'an obslete'. Actually, it should have been 'an obsolete' as that is the correct spelling. Scott (A curmudgeon) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
5.7 Adjusting the Toolchain
Hi there,
I see something wierd in the follwing line from the lfs-6.3 book (it
is in chapter 5.7):
Though I did not check it seems to be the same in the new lfs-6.4 book.
GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \;
rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*`
unset GCC_INCLUDEDIR
this command: GCC_INCLUDEDIR=`dirname $(gcc
-print-libgcc-file-name)`/include
seems to point to a directory on the host system.
On my system it becomes: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
next this line: rm -vf `grep -l DO NOT EDIT THIS FILE
${GCC_INCLUDEDIR}/*`
tries to delete files from my host system.
This is natural because my systems PATH varaible contains:
/usr/local/bin:/bin:/usr/bin
thus it uses the hosts gcc.
I believe it should use the new installed gcc from chapter 5.4.
And therefore the GCC_INCLUDEDIR should be:
/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2/include
Though I am not sure :)
I found this problem in the following way:
I have installed an lfs-6.3 system (that did not seem to have any problems)
using the package uyser system.
For this system I used a differnt kernel (2.6.24.4 instead of 2.6.22.5).
Next I wanted to install a new lfs-6.3 system (using the previous one
as the host)
but now with the regular 2.6.22.5 kernel as described in the lfs-6.3 book.
Again with the package user system.
when the rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*` line
was enterd it gave me a permission error on:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/ssp/{ssp.h,stdio.h,string.h,unistd.h}
Which is good, since these are files from my host system that cannot be deleted
by the lfs user.
I think I did something wrong an hopefully someone can point me somewhere.
Thanks already,
Herman Gerritsen
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 5.7 Adjusting the Toolchain
Hi there,
I overlooked a mistake on my side.
(Somehow these things come to mind after writing a post...)
The LFS users .bashrc contained a wrong $PATH variable
I somehow ommited the /tools/bin...
Thanks anyway, and sorry...
Herman Gerritsen
On Sun, Nov 30, 2008 at 12:57 PM, Herman Gerritsen [EMAIL PROTECTED] wrote:
Hi there,
I see something wierd in the follwing line from the lfs-6.3 book (it
is in chapter 5.7):
Though I did not check it seems to be the same in the new lfs-6.4 book.
GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \;
rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*`
unset GCC_INCLUDEDIR
this command: GCC_INCLUDEDIR=`dirname $(gcc
-print-libgcc-file-name)`/include
seems to point to a directory on the host system.
On my system it becomes: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
next this line: rm -vf `grep -l DO NOT EDIT THIS FILE
${GCC_INCLUDEDIR}/*`
tries to delete files from my host system.
This is natural because my systems PATH varaible contains:
/usr/local/bin:/bin:/usr/bin
thus it uses the hosts gcc.
I believe it should use the new installed gcc from chapter 5.4.
And therefore the GCC_INCLUDEDIR should be:
/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2/include
Though I am not sure :)
I found this problem in the following way:
I have installed an lfs-6.3 system (that did not seem to have any problems)
using the package uyser system.
For this system I used a differnt kernel (2.6.24.4 instead of 2.6.22.5).
Next I wanted to install a new lfs-6.3 system (using the previous one
as the host)
but now with the regular 2.6.22.5 kernel as described in the lfs-6.3 book.
Again with the package user system.
when the rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*`
line
was enterd it gave me a permission error on:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/ssp/{ssp.h,stdio.h,string.h,unistd.h}
Which is good, since these are files from my host system that cannot be
deleted
by the lfs user.
I think I did something wrong an hopefully someone can point me somewhere.
Thanks already,
Herman Gerritsen
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain [SOLVED]
--- On Tue, 7/15/08, Tarsier [EMAIL PROTECTED] wrote:
Philipp, thanks for the logs and let me CC this to the list
too, others also may be aware of this.
After the GCC-4.2.3 - Pass 2, its still not everything get
from /tools. Which is not pure as per our objective, but
since they are temp tools, I think still alright.
To make it more cleaner, in this rebuild I made a specs
file:
gcc -dumpspecs | sed \
-e
'/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/tools/usr/lib/@}'
\
`dirname $(gcc --print-libgcc-file-name)`/specs
I'm still building towards chroot, let see what
happens.
Careful rebuild solved the problem. Thanks everyone who helped me in this
regard.
Tarsier
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
--- On Mon, 7/14/08, Chris Staub [EMAIL PROTECTED] wrote: From: Chris Staub [EMAIL PROTECTED] Subject: Re: Compile error after final Re-adjusting the Toolchain To: LFS Support List lfs-support@linuxfromscratch.org Date: Monday, July 14, 2008, 1:51 PM Tarsier wrote: Oh, what I mean is GCC-4.2.3 - Pass 1 and GCC-4.2.3 - Pass 2 instructions. All necessary dependencies installed. Tarsier Then something is *seriously* wrong, assuming the directory name you gave earlier wasn't a typo... Tarsier wrote: It is getting crtbegin.o, libgcc.a, libgcc_eh.a and crtend.o from /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/ . Any ideas for what went wrong? Tarsier Is that really what it is? If so, that directory name indicates GCC 4.3.1. -- Yep, no typo, I applied the GCC-4.2.3 - Pass 1 and GCC-4.2.3 - Pass 2 instructions to build and install the GCC 4.3.1 and the toolchain. Appreciate if you could refer to my first email, I want to understand why the linking went wrong after building the toolchain. Tarsier -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
On Sun, Jul 13, 2008 at 11:34:33PM -0700, Tarsier wrote: Yep, no typo, I applied the GCC-4.2.3 - Pass 1 and GCC-4.2.3 - Pass 2 instructions to build and install the GCC 4.3.1 and the toolchain. Appreciate if you could refer to my first email, I want to understand why the linking went wrong after building the toolchain. If you want to use a newer major version of gcc, you need to know what has changed, and then you can either correct patches or seds so that they continue to work, or add whatever new instructions and packages are needed. For clfs (which continues to use patches for gcc), I know someone has built with gcc-4.3, but I haven't looked at their findings so I don't know what needed to be changed. For LFS, I don't remember if anyone has built successfully with gcc-4.3 : you might be out on your own. ĸen -- das eine Mal als Tragödie, das andere 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: Compile error after final Re-adjusting the Toolchain
Hi again, my system is running a GCC-4.3.1, which is why I responded in the first place. If you have installed the patches for Glibc-2.7, which should come in two *.diff files, then everything should compile just fine with the development book's instructions - well, at least it worked twice for me. Are you using a 32 bit system? I don't know how I could be of any help for you. Would it help if I compile a dummy file on my machine and send you the output? Have you already tried to re-do chapter 6 with a backup of the chapter 5 toolchain? At least the error occuring in 6.10 indicates that you did something wrong in chapter 6, only that I'm not skilled enough to tell you in any form what happened. - Philipp -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
--- On Mon, 7/14/08, Ken Moffat [EMAIL PROTECTED] wrote:
From: Ken Moffat [EMAIL PROTECTED]
Subject: Re: Compile error after final Re-adjusting the Toolchain
To: lfs-support@linuxfromscratch.org
Date: Monday, July 14, 2008, 8:16 PM
On Sun, Jul 13, 2008 at 11:34:33PM -0700, Tarsier wrote:
Yep, no typo, I applied the GCC-4.2.3 - Pass 1 and
GCC-4.2.3 - Pass 2 instructions to build and install the
GCC 4.3.1 and the toolchain. Appreciate if you could refer
to my first email, I want to understand why the linking
went wrong after building the toolchain.
If you want to use a newer major version of gcc, you need
to know
what has changed, and then you can either correct patches
or seds so
that they continue to work, or add whatever new
instructions and
packages are needed.
For clfs (which continues to use patches for gcc), I know
someone
has built with gcc-4.3, but I haven't looked at their
findings so I
don't know what needed to be changed. For LFS, I
don't remember if
anyone has built successfully with gcc-4.3 : you might be
out on
your own.
I restarted building the Temporary System.
Appreciate very much if someone could send me the following dummy.log (verbose
output of the compilation) after the GCC-4.2.3 - Pass 2 but before chroot:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
This will surely help me to verify whether my Temporary System build properly.
Many thanks in advance.
Tarsier
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
On Jul 14, 2008, at 9:21 AM, Tarsier wrote:
--- On Mon, 7/14/08, Ken Moffat [EMAIL PROTECTED] wrote:
I restarted building the Temporary System.
Appreciate very much if someone could send me the following
dummy.log (verbose output of the compilation) after the GCC-4.2.3 -
Pass 2 but before chroot:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
This will surely help me to verify whether my Temporary System
build properly.
Many thanks in advance.
Tarsier
Look at the thread titled LFS 6.3 gcc output differences (ignoring
nonexistent directory) by [EMAIL PROTECTED] dated July 8, 2008.
I posted output there with their issue.
WIlliam
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
--- On Mon, 7/14/08, Philipp Christian Loewner [EMAIL PROTECTED] wrote:
From: Philipp Christian Loewner [EMAIL PROTECTED]
Subject: Re: Compile error after final Re-adjusting the Toolchain
To: [EMAIL PROTECTED]
Date: Monday, July 14, 2008, 11:16 PM
I restarted building the Temporary System.
Appreciate very much if someone could send me the
following dummy.log
(verbose output of the compilation) after the
GCC-4.2.3 - Pass 2 but
before chroot:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
Here you go: I have got two dummy.log files for you,
but both may not exactly be what you need.
I had a backup of /tools still floating arround
on my disk, then added lfs group and user as in
the beginning of the book, set up the enviroment to use
/tools prior to /usr or / and then compiled a dummy file
as in 6.10.
The two files you were having problems with are taken
from /usr according to the log, but I don't know if
this is supposed to be or if I just oversaw a command,
and I'm in a hurry at the moment and don't have
enough
time to look it over.
That dummy.log file is the first attached file.
Philipp, thanks for the logs and let me CC this to the list too, others also
may be aware of this.
After the GCC-4.2.3 - Pass 2, its still not everything get from /tools. Which
is not pure as per our objective, but since they are temp tools, I think still
alright.
To make it more cleaner, in this rebuild I made a specs file:
gcc -dumpspecs | sed \
-e '/\*startfile_prefix_spec:/{n;[EMAIL
PROTECTED]@/tools/usr/lib/@}' \
`dirname $(gcc --print-libgcc-file-name)`/specs
I'm still building towards chroot, let see what happens.
Tarsier
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Compile error after final Re-adjusting the Toolchain
Hi
I'm getting a compile error after final Re-adjusting the Toolchain(6.10):
1. Rename ld-new to ld
2. gcc -dumpspecs | sed ...
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
attempt to open /usr/lib/libc.so succeeded
:
attempt to open /usr/lib/crtn.o succeeded
/usr/lib/crtn.o/usr/lib/libc.so: undefined reference to ...
/usr/lib/libc.so: undefined reference to ...
/usr/lib/libc.so: undefined reference to ...
/usr/lib/libc.so: undefined reference to ...
/usr/lib/libc.so: undefined reference to ...
collect2: ld returned 1 exit status
It is getting crtbegin.o, libgcc.a, libgcc_eh.a and crtend.o from
/tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/ .
Any ideas for what went wrong?
Tarsier
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
--- On Mon, 7/14/08, Ken Moffat [EMAIL PROTECTED] wrote: From: Ken Moffat [EMAIL PROTECTED] Subject: Re: Compile error after final Re-adjusting the Toolchain To: LFS Support List lfs-support@linuxfromscratch.org Date: Monday, July 14, 2008, 6:30 AM On Sun, Jul 13, 2008 at 07:33:22PM +0200, Philipp Christian Loewner wrote: Hi, first of all I can not promise to be of any help. It is getting crtbegin.o, libgcc.a, libgcc_eh.a and crtend.o from /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/ . Isn't it suppposed to get files belonging to gcc from /tools? Not after the _final_ readjustment, no - at this point it should be ready to build for the final system. But crtbegin.o, libgcc.a, libgcc_eh.a and crtend.o are not installed yet to the /usr, there are still on /tools. What I have on /usr right before the final readjustment are the C libraries, Header files and dynamic linker. There are no shared libraries under /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/. Therefore, it uses static libraries: attempt to open /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/libgcc.so failed attempt to open /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/libgcc.a succeeded All library references, -lgcc -lgcc_eh -lc -lgcc -lgcc_eh, as per COLLECT_GCC_OPTIONS are found. Its only crt1.o, crti.o and crtn.o from /usr/lib/. Issue seems to be cannot link objects/libraries from two different sources, /tools and /usr. So the question is can I? The big problem here is the gcc version Tarsier is using - it doesn't match what's in the book. I know people are using the 4.3 series, but I don't know what changes they've had to make. Trying newer versions, after one is familiar with the build process, is not a bad thing. However, expecting to use a new version of gcc (rather than a new point release) without the instructions changing, is optimistic. And asking for help without mentioning the variation(s) one has made doesn't help anybody. I'm experienced with LFS building. I'm trying as per LFS version SVN-20080711. No instruction were changed for compiler building. Tarsier -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
Tarsier wrote: The big problem here is the gcc version Tarsier is using - it doesn't match what's in the book. I know people are using the 4.3 series, but I don't know what changes they've had to make. Trying newer versions, after one is familiar with the build process, is not a bad thing. However, expecting to use a new version of gcc (rather than a new point release) without the instructions changing, is optimistic. And asking for help without mentioning the variation(s) one has made doesn't help anybody. I'm experienced with LFS building. I'm trying as per LFS version SVN-20080711. No instruction were changed for compiler building. Tarsier That can't be. Using GCC 4.3 with dev LFS simply isn't possible without somehow deviating from the current instructions. For starters, 4.3 requires GMP and MPFR, which are NOT installed anywhere in LFS... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
--- On Mon, 7/14/08, Chris Staub [EMAIL PROTECTED] wrote: From: Chris Staub [EMAIL PROTECTED] Subject: Re: Compile error after final Re-adjusting the Toolchain To: [EMAIL PROTECTED], LFS Support List lfs-support@linuxfromscratch.org Date: Monday, July 14, 2008, 12:39 PM Tarsier wrote: The big problem here is the gcc version Tarsier is using - it doesn't match what's in the book. I know people are using the 4.3 series, but I don't know what changes they've had to make. Trying newer versions, after one is familiar with the build process, is not a bad thing. However, expecting to use a new version of gcc (rather than a new point release) without the instructions changing, is optimistic. And asking for help without mentioning the variation(s) one has made doesn't help anybody. I'm experienced with LFS building. I'm trying as per LFS version SVN-20080711. No instruction were changed for compiler building. Tarsier That can't be. Using GCC 4.3 with dev LFS simply isn't possible without somehow deviating from the current instructions. For starters, 4.3 requires GMP and MPFR, which are NOT installed anywhere in LFS... -- Oh, what I mean is GCC-4.2.3 - Pass 1 and GCC-4.2.3 - Pass 2 instructions. All necessary dependencies installed. Tarsier -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error after final Re-adjusting the Toolchain
Tarsier wrote: Oh, what I mean is GCC-4.2.3 - Pass 1 and GCC-4.2.3 - Pass 2 instructions. All necessary dependencies installed. Tarsier Then something is *seriously* wrong, assuming the directory name you gave earlier wasn't a typo... Tarsier wrote: It is getting crtbegin.o, libgcc.a, libgcc_eh.a and crtend.o from /tools/lib/gcc/$(gcc -dumpmachine)/4.3.1/ . Any ideas for what went wrong? Tarsier Is that really what it is? If so, that directory name indicates GCC 4.3.1. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem in 6.10 Re-adjusting the Toolchain [LFS 6.3]
Hello, I have completed the chapter 5. But I am facing one problem in chapter 6.10 every time. After done all the steps before it, then query the following: $ grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' I got nothing, then I tried with $ grep 'SEARCH.*/lib' dummy.log |sed 's|; |\n|g' And I got only the following output: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/tools/lib) So it seems /tools/lib is not replaced properly. I also got following output by the command $ grep found dummy.log found ld-linux.so.2 at /tools/lib/ld-linux.so.2 I can't go ahead without solving this issue. Can you please tell me what I missed ? Try re-running the perl script to modify the specs file, then grep around that file to make sure the changes took place. Re-compile dummy.c and run the tests again. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem in 6.10 Re-adjusting the Toolchain [LFS 6.3]
On Tue, Feb 26, 2008 at 8:05 AM, mark jones [EMAIL PROTECTED] wrote: Hello, I have completed the chapter 5. But I am facing one problem in chapter 6.10 every time. After done all the steps before it, then query the following: $ grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' I got nothing, then I tried with $ grep 'SEARCH.*/lib' dummy.log |sed 's|; |\n|g' And I got only the following output: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/tools/lib) So it seems /tools/lib is not replaced properly. I also got following output by the command $ grep found dummy.log found ld-linux.so.2 at /tools/lib/ld-linux.so.2 I can't go ahead without solving this issue. Can you please tell me what I missed ? All these problems point to the wrong ld linker being used. At the beginning of Ch. 6.10 there are instructions to move the adjusted ld (/tools/bin/ld-new) to be /tools/bin/ld. That ld should have the correct paths pointing to /usr. So, after making the adjustment moving ld-new to /tools/bin/ld, try this command: $ ld --verbose | grep SEARCH SEARCH_DIR(/tools/i686-pc-linux-gnu/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/lib); If that looks alright, then you've done the ld adjustment correctly in Ch. 5 Binutils Pass 2. Now check if the ld executed by gcc is also doing the right thing: $ gcc -Wl,--verbose 2/dev/null | grep '\(SEARCH\|found\)' SEARCH_DIR(/tools/i686-pc-linux-gnu/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/lib); found ld-linux.so.2 at /lib/ld-linux.so.2 If that's wrong, then gcc isn't using the right ld. Try these commands: $ type ld /tools/bin/ld $ gcc -print-prog-name=ld ld That would show that gcc is using the ld found in $PATH, which is /tools/bin/ld. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Problem in 6.10 Re-adjusting the Toolchain [LFS 6.3]
Hello, I have completed the chapter 5. But I am facing one problem in chapter 6.10 every time. After done all the steps before it, then query the following: $ grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' I got nothing, then I tried with $ grep 'SEARCH.*/lib' dummy.log |sed 's|; |\n|g' And I got only the following output: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/tools/lib) So it seems /tools/lib is not replaced properly. I also got following output by the command $ grep found dummy.log found ld-linux.so.2 at /tools/lib/ld-linux.so.2 I can't go ahead without solving this issue. Can you please tell me what I missed ? Thanks -Same - Looking for last minute shopping deals? Find them fast with Yahoo! Search.-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.10. Re-adjusting the Toolchain: ld-new -- no such file or directory
where could i have missed to copy/install that file? Hi, have a look at chapter 5.12 Binutils. ld-new is installed there. Something must have gone wrong here. thorsten -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
6.10. Re-adjusting the Toolchain: ld-new -- no such file or directory
hi everybody!
i got stuck here, but i got no idea why the linker is missing,
the earlier two commands in 6.10 of the stable lfs-book all
worked:
mv -v /tools/bin/{ld,ld-old}
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
but it seems as i do not have a ld-new to be moved to ld..
where could i have missed to copy/install that file?
thanks,
toby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
error - re-adjusting the toolchain chapter 6
Hi,
received the this error after re-adjusting the toolchain in chapter 6
and running sanity check.
root:~# mv -v /tools/bin/{ld,ld-old}
`/tools/bin/ld' - `/tools/bin/ld-old'
root:~# mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
`/tools/i686-pc-linux-gnu/bin/ld' - `/tools/i686-pc-linux-gnu/bin/ld-
old'
root:~# mv -v /tools/bin/{ld-new,ld}
mv: cannot stat `/tools/bin/ld-new': No such file or directory
root:~# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld
create symbolic link `/tools/i686-pc-linux-gnu/bin/ld' to
`/tools/bin/ld'
root:~# gcc -dumpspecs | \
perl -p -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED];' \
-e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/ @g;' \
`dirname $(gcc --print-libgcc-file-name)`/specs
root:~# echo 'main(){}' dummy.c
root:~# cc dummy.c -Wl,--verbose dummy.log
root:~# readelf -l a.out | grep ': /lib'
readelf: Error: 'a.out': No such file
The problem line from above appears to be - mv: cannot stat
`/tools/bin/ld-new': No such file or directory
Is this a problem with the binutils installation?
If so will I need to rebuild the toolchain of is there a fix which can
be applied?
many thanks
Bob
__
Tiscali Broadband only £7.99 a month for your first 3 months!
http://www.tiscali.co.uk/products/broadband/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Adjusting the toolchain: specs file
Hi, I'm using lfs6.3 livecd an in section 5.7 Adjusting the toolchain, the 'gcc -dumpspecs .' command doesn't appear to run properly. I've tried finding the specs file to verify that its been edited correctly but I can't find it. From other posts I think the specs file should be found at /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/ but theres no file called specs at that location? I've also tried find on both the host an $LFS but not found it? Everything seemed to work ok up to this point but there seems to be something wrong? Can anyone shed any light on this? Thanks Richard -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Issue at 6.10. Re-adjusting the toolchain
I am using LFS v6.2. The host system is the LFS liveCD. I have not intentionally deviated from the book at all. I think I have followed the directions exactly. Up to section 6.10, I have not had any unexpected errors or output that is different from what is described in the book. When I attempted to perform the sanity check at the end of 6.10 I get the error a.out could not be found. Now as I understand it, the absence of a.out means that dummy.c was not compiled. When looking in the dummy.log at the end, I see /tools/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../../i686-pc-linux-gnu/bin /ld: :No such file: No such file or directory Collect2: ld retuned 1 exit status. I am sure I missed something, but I looked back at the other commands and they appear to be just like the book. I am not sure where to go from here. I have looked in the LFS FAQ, search the mailing list archives, and my personal friend google. I hope I have covered all basis. I know the is a newbie question. I hope I have done everything expected before asking for help. I really appreciate any help. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: Issue at 6.10. Re-adjusting the toolchain
On Thu, 2007-08-23 at 11:11 -0500, Bryan J. McBride wrote: Please disregard, I found the issue. Never fails, as soon as I ask for help I find the stupid mistake. Haha, if I had a nickel for every time that happened to me, I'd be buying Bill Gates out with my vast fortune. -- Peter B. Steiger Cheyenne, WY -- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re-adjusting the Toolchain - Section 6.10
Hi,
In section 6.10. Re-adjusting the Toolchain,
mv -v /tools/bin/{ld,ld-old}
outputs an error saying that ld do not exist. It is
true that in /tools/bin instaed of ld ld-old and
ld-new are present. What is to be done ???
Similarly, for
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
gets the following message
cannot stat '/tools/i486-linux-gnu/bin/ld no such file
or directory.
I wonder how i486-linux-gnu suddenly appeared ?
Can somebody help ?
With Regards,
Gopa Kumar
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Re-adjusting the Toolchain - Section 6.10
On 4/27/07, Gopa Kumar [EMAIL PROTECTED] wrote:
Hi,
In section 6.10. Re-adjusting the Toolchain,
mv -v /tools/bin/{ld,ld-old}
outputs an error saying that ld do not exist. It is
true that in /tools/bin instaed of ld ld-old and
ld-new are present. What is to be done ???
Similarly, for
you probably moved /tools/bin/ld already to /tools/bin/ld-old
Just a line later, ld-new is moved to ld and everything is fine.
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
gets the following message
cannot stat '/tools/i486-linux-gnu/bin/ld no such file
or directory.
I wonder how i486-linux-gnu suddenly appeared ?
Can somebody help ?
With Regards,
Gopa Kumar
when you enter gcc -dumpmachine on the command line, it will return
i486-linux-gnu for you. It returns i686-pc-linux-gnu for me. That's
all fine, but also here you have probably already moved the ld binary.
Tijnema
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Re-adjusting the Toolchain - Section 6.10
On 4/27/07, Tijnema ! [EMAIL PROTECTED] wrote: I wonder how i486-linux-gnu suddenly appeared ? What's the output of uname -m? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Re-adjusting the Toolchain - Section 6.10
Hi Dan, It returned i686 Gopa Kumar --- Dan Nicholson [EMAIL PROTECTED] wrote: On 4/27/07, Tijnema ! [EMAIL PROTECTED] wrote: I wonder how i486-linux-gnu suddenly appeared ? What's the output of uname -m? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Adjusting the Toolchain : mv: cannot stat `/tools/bin/ld-new': No such file or directory
Found the mistake,
didn't finish binutils installation :-/
Kai
Kai Ulrich schrieb:
Hallo,
I try to adjust the toolchain
but I dont have an ld-new file to rename !
Went something wrong ?
[EMAIL PROTECTED]:~$ mv -v /tools/bin/{ld,ld-old}
`/tools/bin/ld' - `/tools/bin/ld-old'
[EMAIL PROTECTED]:~$ mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
`/tools/i686-pc-linux-gnu/bin/ld' - `/tools/i686-pc-linux-gnu/bin/ld-old'
[EMAIL PROTECTED]:~$ mv -v /tools/bin/{ld-new,ld}
mv: cannot stat `/tools/bin/ld-new': No such file or directory
Regards
Kai
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Between 6.9 and 6.10 Re-adjusting the toolchain
If you are now saying that you knew it had failed, why did you continue ? (Your words here can be interpreted in at least 2 ways, so maybe you're saying you fell out of chroot because it failed and you didn't notice). no, on purpose :/ On a straight-through build (compared to doing a bit, shutting down, and triggering the error when you resumed) you have potentially installed the new linux-libc-headers and glibc into the host system. Depending on the damage, you might need to reinstall the host's system (although I think that is a remote possibility, but bear it in mind if compiles break or you get odd behaviour when you try to run programs). How can I test this? perhaps re-compile my kernel? If the failure to chroot happens again, note the error and ask for help if you can't diagnose it. noted -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Between 6.9 and 6.10 Re-adjusting the toolchain
I kinda messed up after trying the first part in 6.10. Re-adjusting the toolchain. w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory Since I didnt have the i486-linux I changed the $(gcc -dumpmachine) to i686-linux which I have, but in this process I accidently cp -v over the ld in /tools/bin/ld and /tools/i686-linux/bin/ld. the toolchain obviously doesnt work: w00t:/LFS# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/i386-linux/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); Where do I go from here? Sorry for my lack of experience. Thanks in advance, ~djr -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Between 6.9 and 6.10 Re-adjusting the toolchain
On 10/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I kinda messed up after trying the first part in 6.10. Re-adjusting the toolchain. w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory Since I didnt have the i486-linux I changed the $(gcc -dumpmachine) to i686-linux which I have, but in this process I accidently cp -v over the ld in /tools/bin/ld and /tools/i686-linux/bin/ld. It seems like you're probably using the host's gcc since I think the one you built should say i686 unless you manually hacked it. Is /tools/bin at the beginning of your PATH? What's the output from /tools/bin/gcc -dumpmachine? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Between 6.9 and 6.10 Re-adjusting the toolchain
On 10/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I kinda messed up after trying the first part in 6.10. Re-adjusting the toolchain. w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory w00t:/LFS# ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld create symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld' ln: creating symbolic link `/tools/i486-linux/bin/ld' to `/tools/bin/ld': No such file or directory Since I didnt have the i486-linux I changed the $(gcc -dumpmachine) to i686-linux which I have, but in this process I accidently cp -v over the ld in /tools/bin/ld and /tools/i686-linux/bin/ld. It seems like you're probably using the host's gcc since I think the one you built should say i686 unless you manually hacked it. Is /tools/bin at the beginning of your PATH? What's the output from /tools/bin/gcc -dumpmachine? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page /tools/bin/gcc -dumpmachine i686-pc-linux-gnu -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Between 6.9 and 6.10 Re-adjusting the toolchain
On Mon, Oct 16, 2006 at 06:55:17PM +0200, [EMAIL PROTECTED] wrote: No such file or directory Since I didnt have the i486-linux I changed the $(gcc -dumpmachine) to i686-linux which I have, but in this process I accidently cp -v over the ld in /tools/bin/ld and /tools/i686-linux/bin/ld. So, gcc -dumpmachine thought you were on i486, but the things you had built were for i686. the toolchain obviously doesnt work: w00t:/LFS# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' SEARCH_DIR(/usr/i386-linux/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); You seem to be in /LFS when I would really expect you to be in / (that is, /mnt/lfs) although you are root. This sort of suggests you aren't in chroot, in which case you have probably trashed the files in /tools. My /LFS is the /mnt/lfs The big question is, did you forget to chroot, or did the command to do so fail ? Since it failed I exited the chroot environment ~djr -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Between 6.9 and 6.10 Re-adjusting the toolchain
On Mon, Oct 16, 2006 at 07:59:18PM +0200, [EMAIL PROTECTED] wrote: You seem to be in /LFS when I would really expect you to be in / (that is, /mnt/lfs) although you are root. This sort of suggests you aren't in chroot, in which case you have probably trashed the files in /tools. My /LFS is the /mnt/lfs The big question is, did you forget to chroot, or did the command to do so fail ? Since it failed I exited the chroot environment If you are now saying that you knew it had failed, why did you continue ? (Your words here can be interpreted in at least 2 ways, so maybe you're saying you fell out of chroot because it failed and you didn't notice). On a straight-through build (compared to doing a bit, shutting down, and triggering the error when you resumed) you have potentially installed the new linux-libc-headers and glibc into the host system. Depending on the damage, you might need to reinstall the host's system (although I think that is a remote possibility, but bear it in mind if compiles break or you get odd behaviour when you try to run programs). If the failure to chroot happens again, note the error and ask for help if you can't diagnose it. Ken -- das eine Mal als Tragödie, das andere 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: 4. Chapter 5 part 7 adjusting the toolchain
Dear all,
thanks for your help. gcc -dumpmachine was indeed pointing to a
non-existent folder. I have started from scratch and checked gcc
-dumpmachine after each installation. It is now pointing to
i686-pc-linux-gnu, so I assume I made a typo while compling GCC.
Thanks again
Simon
On 04/10/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Send lfs-support mailing list submissions to
lfs-support@linuxfromscratch.org
To subscribe or unsubscribe via the World Wide Web, visit
http://linuxfromscratch.org/mailman/listinfo/lfs-support
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of lfs-support digest...
Today's Topics:
1. Re: Chapter 5 part 7 adjusting the toolchain (Simon Needham)
2. Re: Chapter 5 part 7 adjusting the toolchain (Bauke Jan Douma)
3. Re: Chapter 5 part 7 adjusting the toolchain
(Mag. Leonhard Landrock)
--
Message: 1
Date: Tue, 3 Oct 2006 19:54:07 +0100
From: Simon Needham [EMAIL PROTECTED]
Subject: Re: Chapter 5 part 7 adjusting the toolchain
To: lfs-support@linuxfromscratch.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=UTF-8; format=flowed
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
The message is of course self explanatory, but I have double checked
all my steps upto this point and don't appear to have missed anything.
I have just proceeded on with the installation of the other packages
and the toolchain check. The toolchain check works fine and TCL
installs. Expect however, doesn't.
Anyone able to help or spot what I have missed?
I am running LFS 6.2 and using the Live Cd as a host system.
Thank you in advance
Dr Simon Needham
--
Message: 2
Date: Tue, 03 Oct 2006 21:09:43 +0200
From: Bauke Jan Douma [EMAIL PROTECTED]
Subject: Re: Chapter 5 part 7 adjusting the toolchain
To: LFS Support List lfs-support@linuxfromscratch.org,
[EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=UTF-8; format=flowed
Simon Needham wrote:
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
I don't have an LFS installation, so this is just a 'blind'
comment based on just what you mention here, but I'd say
apparently output from $(gcc -dumpmachine) is null.
That may be a clue to resolution.
What does gcc -dumpmachine from the command-line at this point
say?
Thank you in advance
Dr Simon Needham
Bauke Jan DOuma
--
Message: 3
Date: Tue, 3 Oct 2006 21:52:56 +0200
From: Mag. Leonhard Landrock [EMAIL PROTECTED]
Subject: Re: Chapter 5 part 7 adjusting the toolchain
To: LFS Support List lfs-support@linuxfromscratch.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=utf-8
Am Dienstag, 3. Oktober 2006 20:54 schrieb Simon Needham:
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
The message is of course self explanatory, but I have double checked
all my steps upto this point and don't appear to have missed anything.
As already posted: The problem lies in the output of $(gcc -dumpmachine). A
look at the manual page (man gcc-4.0) says to me:
-dumpmachine
Print the compiler's target machine (for example,
i686-pc-linux-gnu)---and
don't do anything else.
First look wether the option dumpmachine works by
issuing gcc -dumpmachine. If successful, have a look wether the
corresponding path as expected by /tools/$(gcc -dumpmachine)/bin/ really
exists.
Nevertheless I'm afraid, that most likely gcc -dumpmachine will not work for
you. But there are people on this list who for sure can help in that case.
BTW: Have a look at the manual page of bash - section Command Substitution:
Command substitution allows the output of a command to replace the command
name. There are two forms:
$(command )
or
`command`
Bash performs the expansion by executing command and replacing the command
substitution with the standard output of the command, with any trailing
newlines deleted.
I have just proceeded on with the installation of the other packages
and the toolchain check.
Bad idea! In case of such an obvious error, have a look at the LFS pages or
ask for help.
The toolchain check works fine and TCL
installs. Expect however, doesn't
Re: Chapter 5 part 7 adjusting the toolchain
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
The message is of course self explanatory, but I have double checked
all my steps upto this point and don't appear to have missed anything.
I have just proceeded on with the installation of the other packages
and the toolchain check. The toolchain check works fine and TCL
installs. Expect however, doesn't.
Anyone able to help or spot what I have missed?
I am running LFS 6.2 and using the Live Cd as a host system.
Thank you in advance
Dr Simon Needham
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Chapter 5 part 7 adjusting the toolchain
Simon Needham wrote:
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
I don't have an LFS installation, so this is just a 'blind'
comment based on just what you mention here, but I'd say
apparently output from $(gcc -dumpmachine) is null.
That may be a clue to resolution.
What does gcc -dumpmachine from the command-line at this point
say?
Thank you in advance
Dr Simon Needham
Bauke Jan DOuma
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Chapter 5 part 7 adjusting the toolchain
Am Dienstag, 3. Oktober 2006 20:54 schrieb Simon Needham:
I am getting stuck while adjusting the toolchain. When I try to move
the files with:
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
I get an error message:
mv: cannot stat '/tools/bin/ld' : No such file or directory
The message is of course self explanatory, but I have double checked
all my steps upto this point and don't appear to have missed anything.
As already posted: The problem lies in the output of $(gcc -dumpmachine). A
look at the manual page (man gcc-4.0) says to me:
-dumpmachine
Print the compiler's target machine (for example,
i686-pc-linux-gnu)---and
don't do anything else.
First look wether the option dumpmachine works by
issuing gcc -dumpmachine. If successful, have a look wether the
corresponding path as expected by /tools/$(gcc -dumpmachine)/bin/ really
exists.
Nevertheless I'm afraid, that most likely gcc -dumpmachine will not work for
you. But there are people on this list who for sure can help in that case.
BTW: Have a look at the manual page of bash - section Command Substitution:
Command substitution allows the output of a command to replace the command
name. There are two forms:
$(command )
or
`command`
Bash performs the expansion by executing command and replacing the command
substitution with the standard output of the command, with any trailing
newlines deleted.
I have just proceeded on with the installation of the other packages
and the toolchain check.
Bad idea! In case of such an obvious error, have a look at the LFS pages or
ask for help.
The toolchain check works fine and TCL
installs. Expect however, doesn't.
Anyone able to help or spot what I have missed?
I am running LFS 6.2 and using the Live Cd as a host system.
Thank you in advance
Dr Simon Needham
Kind regards,
Leonhard
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
RE: package users: re-adjusting the toolchain
Angel Tsankov wrote: As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. I was talking about LFS version 6.1.1 rather than 6.2. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Angel Tsankov wrote: As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. For LFS 6.1.1 the instructions says Install the adjusted linker by running the following command from within the binutils-build directory: The make -C ld ... install command is different to the LFS 6.2 commands but is still manipulating (in 6.1.1 overwriting) the linker (ld) from the binutils package so it must still be run as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. In 6.1.1 you're still manipulating the same gcc specs file with an almost identical command, so it must still be run as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. In 6.1.1 it's section 6.12 which has less thourough checks, but the same applies. I was talking about LFS version 6.1.1 rather than 6.2. Sorry you did mention that but I clicked my bookmark to the 'stable' version too quickly. BTW, I know the commands are sometimes quite cryptic but if you figure out which file(s) they are manipulating then you just have to look which user owns the files from that package and that's the user to use. The whole principle of the package users method is that only the user who owns the package has the permissions to manipulate the files from that package. (Root has permissions too, of course, but that's what you are avoiding with package users.) In most cases, you will get a warning or error message related to permissions if you use the wrong user. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. For LFS 6.1.1 the instructions says Install the adjusted linker by running the following command from within the binutils-build directory: The make -C ld ... install command is different to the LFS 6.2 commands but is still manipulating (in 6.1.1 overwriting) the linker (ld) from the binutils package so it must still be run as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. In 6.1.1 you're still manipulating the same gcc specs file with an almost identical command, so it must still be run as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. In 6.1.1 it's section 6.12 which has less thourough checks, but the same applies. I was talking about LFS version 6.1.1 rather than 6.2. Sorry you did mention that but I clicked my bookmark to the 'stable' version too quickly. BTW, I know the commands are sometimes quite cryptic but if you figure out which file(s) they are manipulating then you just have to look which user owns the files from that package and that's the user to use. The whole principle of the package users method is that only the user who owns the package has the permissions to manipulate the files from that package. (Root has permissions too, of course, but that's what you are avoiding with package users.) In most cases, you will get a warning or error message related to permissions if you use the wrong user. Thanks, Brandon! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Angel Tsankov wrote: As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? If you need to ask this, you shouldn't be using package users. Besides, the whole toolchain readjustment only affects stuff in /tools, so it doesn't make any difference what user you use. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Brandon Peirce wrote: Angel Tsankov wrote: For LFS 6.1.1 the instructions says Install the adjusted linker by running the following command from within the binutils-build directory: The make -C ld ... install command is different to the LFS 6.2 commands but is still manipulating (in 6.1.1 overwriting) the linker (ld) from the binutils package so it must still be run as your binutils package user. The adjusted linker is installed into /tools, so you need to use root. In 6.1.1 you're still manipulating the same gcc specs file with an almost identical command, so it must still be run as your gcc package user. Again, this is done in /tools, so it also should be done as root. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Chris Staub wrote: The adjusted linker is installed into /tools, so you need to use root. Why root? Of course you can always achieve this with root, but that's kind of missing the point of package users technique, (and also violating principle of least privelege). I concede that the motivation for why you would use the package users technique in the first place is much less applicable to the installations in /tools than to the final installations in /usr. However from reading the experiences of people who have used this technique, they all say that you should start with it from the beginninig because you make life really difficult for yourself if you try to switch half-way. I therefore assume that if Angel has got this far with package users, he has been using them also in Ch 5. I'm also assuming that the numeric user IDs of the package users in the chroot match those on the host, otherwise it will be a real mess. Hmmm. A lot of assumptions. I concur with your earlier statement about the level of experience need to use the package users technique compared with the type of questions asked. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Brandon Peirce wrote: Why root? Of course you can always achieve this with root, but that's kind of missing the point of package users technique, (and also violating principle of least privelege). I concede that the motivation for why you would use the package users technique in the first place is much less applicable to the installations in /tools than to the final installations in /usr. However from reading the experiences of people who have used this technique, they all say that you should start with it from the beginninig because you make life really difficult for yourself if you try to switch half-way. I therefore assume that if Angel has got this far with package users, he has been using them also in Ch 5. I'm also assuming that the numeric user IDs of the package users in the chroot match those on the host, otherwise it will be a real mess. You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. Hmmm. A lot of assumptions. I concur with your earlier statement about the level of experience need to use the package users technique compared with the type of questions asked. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Chris Staub wrote: You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. From the hint: Build Chapter 5 exactly as explained by the LFS book. There is only one little change you have to make. After running `make install' for the coreutils package, issue the following command (still from within the coreutils build directory): cp src/su /tools/bin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. Why glibc only?! What about Linux Libc headers and Man pages - the hint recommends to install them using PU? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Angel Tsankov wrote: You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. Why glibc only?! What about Linux Libc headers and Man pages - the hint recommends to install them using PU? Well, yeah, those too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Chris Staub wrote: Chris Staub wrote: You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. From the hint: Build Chapter 5 exactly as explained by the LFS book. There is only one little change you have to make. After running `make install' for the coreutils package, issue the following command (still from within the coreutils build directory): cp src/su /tools/bin OK, I see the approach. Thx for pointing that out. Root it is, then. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
LFS 6.1.1: Re-adjusting the toolchain in chapter 6 fails to install binutils from pass 2 in chapter 5
Hallo! I'm trying to build a LFS system from the LFS LiveCD and I've come to section 6.12. Re-adjusting the Toolchain. Then I noticed that the make -C ld INSTALL=/tools/bin/install install command does not get executed properly, as the binutils-build/Makefile contains paths that do not exist in the chroot environment. All these are absolute paths beginning with /mnt/lfs. Since this is the root of the chroot'ed environment it does not exist in it. As far as I understand the note in section 6.12, I have the choice to skip the above command, or ... probably, exit the chroot, execute the command, and then reenter the chroot. Which option should I select? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.1.1: Re-adjusting the toolchain in chapter 6 fails to install binutils from pass 2 in chapter 5
On 4/27/06, Angel Tsankov [EMAIL PROTECTED] wrote: make -C ld INSTALL=/tools/bin/install install command does not get executed properly, as the binutils-build/Makefile contains paths that do not exist in the chroot environment. All these are absolute paths beginning with /mnt/lfs. Since this is the root of the chroot'ed environment it does not exist in it. I've never heard of people having this problem before. Are the paths (with /mnt/lfs) included in binutils-build/ld/Makefile as well? As far as I understand the note in section 6.12, I have the choice to skip the above command, or ... probably, exit the chroot, execute the command, and then reenter the chroot. Which option should I select? Don't skip the command unless you really need to. You could probably run the command from outside the chroot. Or, you could just strip off the /mnt/lfs prefixes that are causing you problems. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.1.1: Re-adjusting the toolchain in chapter 6 failstoinstall binutils from pass 2 in chapter 5
Could a problem in previous steps result in these makefiles using absolute paths? You didn't configure binutils in the chapter 5 with --prefix=/mnt/lfs/tools, did you? Here's how I configured binutils in chapter 5, pass 2: === echo 'Started building binutils (pass 2).' cd $LFS/sources tar -xjf binutils-2.15.94.0.2.2.tar.bz2 # build in a separate directory mkdir -v $LFS/builds/binutils-2.15.94.0.2.2 cd $LFS/builds/binutils-2.15.94.0.2.2 $LFS/sources/binutils-2.15.94.0.2.2/configure \ --prefix=/tools \ --disable-nls \ --enable-shared \ --with-lib-path=/tools/lib make make install make -C ld clean make -C ld LIB_PATH=/usr/lib:/lib # do not remove the soruce or build directories yet echo 'Finished building binutils (pass 2).' === And here's how I did it in pass 1: === echo 'Started building binutils.' cd $LFS/sources tar -xjf binutils-2.15.94.0.2.2.tar.bz2 # build in a separate directory mkdir -v $LFS/builds/binutils-2.15.94.0.2.2 cd $LFS/builds/binutils-2.15.94.0.2.2 $LFS/sources/binutils-2.15.94.0.2.2/configure --prefix=/tools --disable-nls make make install make -C ld clean make -C ld LIB_PATH=/tools/lib # do not remove source or build directories yet echo 'Finished building binutils.' === -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
LFS-Book 5.7 Adjusting the Toolchain
Hallo Everybody!
May I present you the following result:
$ SPECFILE=`gcc --print-file specs`
sed 's@ /lib/ld-linux.so.2@ /tools/lib/[EMAIL PROTECTED]' \
$SPECFILE tempspecfile
mv -f tempspecfile $SPECFILE
unset SPECFILE
mv: Verschieben zwischen Geräten fehlgeschlagen: ,,tempspecfile zu
,,/usr/lib/gcc/i486-pc-linux-gnu/3.4.3/specs;
moving between didn't work
kann Ziel nicht entfernen: Keine Berechtigunglfslivecd:lfs | Fre 13 Jän
2006 10:07:49 GMT | /mnt/lfs/sources/binutils-build
Can't remove target, no permission
$ rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
lfslivecd:lfs | Fre 13 Jän 2006 10:08:14 GMT |
/mnt/lfs/sources/binutils-build
$ echo 'main(){}' dummy.c
lfslivecd:lfs | Fre 13 Jän 2006 10:08:31 GMT |
/mnt/lfs/sources/binutils-build
$ cc dummy.c
Unable to handle kernel NULL pointer dereference at virtual address
00b4
printing eip:
c0159fa5
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: nfs lockd sunrpc ext2 reiserfs ne2k_pci 8390
intel_agp agpgart unionfs
CPU:0
EIP:0060:[c0159fa5]Not tainted VLI
EFLAGS: 00010246 (2.6.11.12)
EIP is at dentry_open+0x45/0x2a0
eax: 000d ebx: cf4c1b00 ecx: edx: cd1e6900
esi: edi: ebp: cffd7f80 esp: cd31de68
ds: 007b es: 007b ss: 0068
Process cc (pid: 26877, threadinfo=cd31c000 task=cf4e1060)
Stack: ffe9 cffd7f80 cea8b6e0 cd1e6900 d0d8a952
cd1e6900
cffd7f80 cbd82cc8 0002 c0167efd ce8c0558
0002
cfd1fc00 ce699a90 0002 0001
cd31df60
Call Trace:
[d0d8a952] unionfs_open+0xd92/0xf90 [unionfs]
[c0167efd] permission+0x6d/0xa0
[c0167f19] permission+0x89/0xa0
[c01697bb] may_open+0x4b/0x1e0
[c03ed6be] _spin_lock+0xe/0x80
[c015a144] dentry_open+0x1e4/0x2a0
[c0159f50] filp_open+0x50/0x60
[c015a395] sys_open+0x35/0x90
[c01030e7] syscall_call+0x7/0xb
Code: 00 00 85 c0 89 c3 0f 84 64 01 00 00 89 70 18 8d 46 01 83 e0 03 83
c8 0c 66 89 43 1c 8b 54 24 1c a8 02 8b 7a 10 0f 85 2b 01 00 00 8b 87
b4 00 00 00 89 83 98 00 00 00 8b 44 24 1c 89 43 08 89 6b
Speicherzugriffsfehler
lfslivecd:lfs | Fre 13 Jän 2006 10:08:38 GMT |
/mnt/lfs/sources/binutils-build
I hope it could be readable. Second Ops after complete new start
from the very beginning. Machine changing now :-(
Kind regards
Clemens ;-)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
RE-adjusting the Toolchain
Hi,
I'm currently in Chapter 6, section 6.12, of the LFS book version 6.1. It's
the section where we re-adjust the toolchain. The book says to adjust the
gcc specs file to remove the reference to /tools/lib/ld-linux.so.2, and
replace it with /{,usr/}lib/ld-linux.so.2. Now, I understand this to mean
that we are specifying two paths - /lib/ld-linux.so.2, and
/usr/lib/ld-linux.so.2. However, how do I enter this into the specs file? If
I enter it exactly as shown in the book, using the curly brackets - {,usr/},
then when you do the sanity check with dummy.c, and then readelf on a.out
and grep the output for ': /lib', grep does not find that path, because it
doesn't exist as such - it exists as /{,usr/} etc.
I was just wondering if anyone could shed any light on this for me - have I
done it right by specifying the path as /{.usr/}lib in the specs file, or do
I need to enter the path twice, or is there some other method that I've
overlooked?
Thanks in advance for your help,
Paul
---
Paul Lewis ([EMAIL PROTECTED])
JCR Computing Rep
St Anne's College
http://www.stannesjcr.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: RE-adjusting the Toolchain
On 11/1/05, Paul Lewis [EMAIL PROTECTED] wrote:
The book says to adjust the
gcc specs file to remove the reference to /tools/lib/ld-linux.so.2, and
replace it with /{,usr/}lib/ld-linux.so.2. Now, I understand this to mean
that we are specifying two paths - /lib/ld-linux.so.2, and
/usr/lib/ld-linux.so.2.
That's not actually what's said. Hopefully you've already been
steered correctly with the perl command, but just to make sure you're
not going down the wrong path, you should only have
/lib/ld-linux.so.2. If there's another one in /usr/lib, you've got
issues. The other part about /usr/lib is to make sure that the gcc
you're about to compile looks in /usr/lib first for the glibc
startfiles in /usr/lib rather than in /tools/lib.
Of course, you probably already took Matthew's advice and are down the
road somewhere by now.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 5.7 Adjusting the Toolchain .?
Perhaps you haven't set your PATH correctly - you should be using programs from /tools/bin in preference to the host's /bin and /usr/bin, so gcc should already be in /tools. yes , you are right . because I'm using live cd so , i should set my PATH every time ... ; there is some good script on (How to build a LFS 6.1 system using the LFS live CD as your host OS) article . I've forgot to use that script . Thanks for your attention . -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
