LinuxQuestions.org

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

SuMZ 01-08-2013 08:54 PM

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.

druuna 01-09-2013 01:04 AM

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.

SuMZ 01-09-2013 06:01 AM

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?

McZ 01-09-2013 06:36 AM

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.

druuna 01-09-2013 06:56 AM

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.

SuMZ 01-09-2013 08:10 PM

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.

druuna 01-10-2013 08:51 AM

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.

cjbreisch 01-11-2013 07:31 PM

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.


All times are GMT -5. The time now is 09:08 AM.