On 1/4/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > No. It's more complicated than that :-/ GCC also has a say in the library > search path too. This is why the startfile_prefix_spec hack to GCC makes > it (mostly) do the right thing.
The directory is passed as a -L flag to the linker by gcc. Verified that by replacing /tools/bin/ld by a shell script. > 3. Find some other solution. DIY currently does some funky stuff with > specs and -L/usr/lib and -B/usr/lib/, which works fine for standard > x86 builds but is untested (by me at least) for multilib builds and > may not work there. I perfer this option. I would prefer making shell scripts /usr/bin/gcc (with a symlink from /usr/bin/cc) and /usr/bin/ld during the Ch 6 toolchain adjustment phase. The gcc script should call "exec /tools/bin/gcc -B/usr/lib $@" and /usr/bin/ld should call "exec /tools/bin/ld -nostdlib -L/usr/lib -L/lib $@". This way we also avoid the need to keep the binutils build dir around. > BTW, DIY uses a much enhanced series of sanity checks in the toolchain > readjustemnt step which would have caught this flaw immediately. In view > of the current situation, LFS may want to adopt something similar.. tho' > the DIY sanity checks are geared towards scripting and rely upon the exit > status of `grep'. LFS would therefore need to adjust and/or word it > appropriately. The sanity checks are good. For LFS, it would be OK to just add "cc dummy.c -Wl,--verbose 2>&1 | grep succeeded" and ask folks to check the output. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
