LinuxQuestions.org - LFS7.2, problem when chapter 6.10: adjusting the toolchain, can not change gcc specs

- Linux From Scratch (https://www.linuxquestions.org/questions/linux-from-scratch-13/)

- - LFS7.2, problem when chapter 6.10: adjusting the toolchain, can not change gcc specs (https://www.linuxquestions.org/questions/linux-from-scratch-13/lfs7-2-problem-when-chapter-6-10-adjusting-the-toolchain-can-not-change-gcc-specs-4175444755/)

LFS7.2, problem when chapter 6.10: adjusting the toolchain, can not change gcc specs

Hi guys.
I meet a weired problem. I'm just finishing chapter 6.9 glibc-2.16.0, now I need to adjust my toolchain.

Here is the code from book I run:

Code:

gcc -dumpspecs | sed -e 's@/tools@@g' \

-e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \

-e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \

`dirname $(gcc --print-libgcc-file-name)`/specs

and I get a file named specs in /tools/lib/gcc/i686-pc-linux-gnu/4.7.1/ , in which it says:

Quote:

*dynamic_linker:
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/lib/ld-linux.so.2}}

and I run gcc -v, here is the print:

Quote:

root:/# gcc -v
Reading specs from /tools/lib/gcc/i686-pc-linux-gnu/4.7.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tools/libexec/gcc/i686-pc-linux-gnu/4.7.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.1/configure --prefix=/tools --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --enable-clocale=gnu --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch --disable-multilib --disable-bootstrap --disable-libgomp --with-mpfr-include=/mnt/lfs/sources/gcc-build/../gcc-4.7.1/mpfr/src --with-mpfr-lib=/mnt/lfs/sources/gcc-build/mpfr/src/.libs
Thread model: posix
gcc version 4.7.1 (GCC)

But, if I run gcc -dunpspecs, I get this in output:

Quote:

*dynamic_linker:
%{muclibc:/tools/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/tools/lib/ld-linux.so.2}}

Then I'm confused why this happens.
Does anyone has any idea? Thank you.

Maybe I'm still half asleep, but what is the actual problem?

The first gcc -dumpspecs command you posted is changed by sed and put in a file and the second gcc -dumpspecs command you post is just the bare, unchanged output.

Hi, druuna, thanks for your reply.

Here is the problem, the gcc -v says gcc is using the specs file created by first gcc -dumpspecs and sed command,
but the second gcc -dumpspecs still prints out unchanged specs.

Should this be a problem? or gcc -dumpspecs just always gives original built-in specs?

IIRC there is nothing in the book on running gcc -dumpspec twice to verify, do the other tests to verify the toolchain. if they are not correct then there is a problem, but if the tests works then there is no problem and correct specs are used.

Quote:

Originally Posted by SuMZ (Post 4866015)

Here is the problem, the gcc -v says gcc is using the specs file created by first gcc -dumpspecs and sed command,
but the second gcc -dumpspecs still prints out unchanged specs.

Should this be a problem? or gcc -dumpspecs just always gives original built-in specs?

Curiosity is a great thing, but can also be confusing ;)

gcc -dumpspecs prints all of the built in spec strings. gcc will use the spec file when doing its thing.

Quote:

gcc -dumpspecs prints all of the built in spec strings. gcc will use the spec file when doing its thing.

Oh, I see, thanks. Here is the reason why I ask this question:

I'm test toolchain following chapter 6.10 in LFS7.2:

Quote:

echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

It looks alright:

Quote:

[Requesting program interpreter: /lib/ld-linux.so.2]

next, test startfiles:

Quote:

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

again, looks alright:

Quote:

/usr/lib/crt1.o succeeded
/usr/lib/crti.o succeeded
/usr/lib/crtn.o succeeded

next, test header files:

Quote:

grep -B1 '^ /usr/include' dummy.log

again, looks alright:

Quote:

#include <...> search starts here:
/usr/include

But, next test search paths:

Quote:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

It prints out nothing.

next test libc:

Quote:

grep "/lib.*/libc.so.6 " dummy.log

it is not correct:

Quote:

attempt to open /tools/lib/libc.so.6 succeeded

then finally test dynamic linker:

Quote:

grep found dummy.log

it is still not correct:

Quote:

found ld-linux.so.2 at /tools/lib/ld-linux.so.2

I thought it caused by wrong gcc specs, but now it seems not be that reason.
Can you see what's wrong here?
Thank you.

Quote:

Originally Posted by SuMZ (Post 4866609)

I thought it caused by wrong gcc specs, but now it seems not be that reason.
Can you see what's wrong here?

The output is indeed not correct. Or better: half is correct and the other half isn't. I'm not able to point you to anything specific, but this does need to be fixed before you continue.

I do find it curious that half the entries are correct (no /tools) and the other half does have the (incorrect) /tools part. Never seen that before.

Quote:

Originally Posted by SuMZ (Post 4866609)

Oh, I see, thanks. Here is the reason why I ask this question:
it is not correct:
Quote:

Quote:

attempt to open /tools/lib/libc.so.6 succeeded

I'm a newbie here. druuna knows much more than me, but this looks like "/tools" wasn't removed from your search path. So, I'd say that the changes to dumpspecs failed.

I had a similar problem. What worked for me was to break it down into pieces. I did a gcc -dumpspecs > specs.org before the sed. Then I did another gcc -dumpspecs and piped that through the first sed, and sent that to sed.out. Then the second sed on sed.out > sed2.out. Then the third sed on sed2.out > sed3.out. Then copied sed3.out into the specs file.

After each step I diffed the output against the original specs file (specs.orig) to see if there were any changes and if the changes made sense.

If they all do, then look at gcc --print-libgcc-filename, and make sure that makes sense as well, although I can't imagine how anything would work if that was wrong.