Re: [lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
On Jun 25, 2013, at 9:37 AM, Aleksandar Kuktin wrote: I think you can just go on. Whats important is that the new program requests /lib/ld-linux.so.2 (or other, but in /lib) for its run-time linker. That linker is part of the new glibc, which means that new libraries will be used by your program. This will be correct as after binutils is built, the new linker will default to /lib /usr/lib and not include /tools/lib. When doing the toolchain test after gcc in ch6, it'll be using the new linker and SEARCH_DIR will be back to defaults. 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] Getting incorrect search results, mentioned in Errata for section 6.10
>On Tue, 25 Jun 2013 12:56:35 +0300 >Sergey Shidlovsky wrote: > > Hi again! =) > > One more question, if you please. > > While adjusting toolchain, we do such search: > > ** > echo 'main(){}' > dummy.c > cc dummy.c -v -Wl, --verbose &> dummy.log > > ... > > Next, verify that the new linker is being used with the correct search > paths: > > grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' > > If everything is working correctly, there should be no errors, and the > output of the last command (allowing for platform-specific target > triplets) will be: > > SEARCH_DIR("/tools/i686-pc-linux-gnu/lib") > SEARCH_DIR("/usr/lib") > SEARCH_DIR("/lib"); > ** > > Errata for section 6.10 of LFS 7.3 stable book says that: > > ** > In Section 6.10, the results of the grep for SEARCH should not > include: SEARCH_DIR("/tools/i686-pc-linux-gnu/lib") > ** > > But I DO get this string in the output. Is it ok, or something went > wrong? > I think you can just go on. Whats important is that the new program requests /lib/ld-linux.so.2 (or other, but in /lib) for its run-time linker. That linker is part of the new glibc, which means that new libraries will be used by your program. And besides - the next step is building of GCC which won't use /tools//lib and thus the entire problem will just go away. You can double-check that the problem did go away by (re)moving /tools, but make sure you first have a working system outside of /tools. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
Hi again! =) One more question, if you please. While adjusting toolchain, we do such search: ** echo 'main(){}' > dummy.c cc dummy.c -v -Wl, --verbose &> dummy.log ... Next, verify that the new linker is being used with the correct search paths: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' If everything is working correctly, there should be no errors, and the output of the last command (allowing for platform-specific target triplets) will be: SEARCH_DIR("/tools/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/lib") SEARCH_DIR("/lib"); ** Errata for section 6.10 of LFS 7.3 stable book says that: ** In Section 6.10, the results of the grep for SEARCH should not include: SEARCH_DIR("/tools/i686-pc-linux-gnu/lib") ** But I DO get this string in the output. Is it ok, or something went wrong? -- Yours faithfully, Sergey N Shidlovsky -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page