>On Tue, 25 Jun 2013 12:56:35 +0300 >Sergey Shidlovsky <[email protected]> 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/<triplet>/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
