On 8/29/06, Dan Nicholson <dbn.lists gmail.com> wrote:
> On 8/29/06, George Boudreau <georgeblinuxfromscratch.org> wrote:
> > Dan Nicholson wrote:
> > >
> > > This definitely happens for binaries created
before the final gcc. Do
> > > you see it on all the binaries, even after
gcc has been installed?
> > .. I cannot say 100% of binaries are this way
but way too many are.
>
> For instance, /bin/ls from coreutils should not
reference the gcc in
> /tools in any way. What do you see there?
George sent me his /bin/lsmod off list.
It took me a couple minutes to figure out the reference to
/tools.
Grep showed a match, but strings didn't show anything.
Bizarre.
Then I remembered objdump. Ken uses it in Farce as a last
resort to do
really low level comparisons.
Try `objdump -s lsmod'. The reference is in a section
called
.debug_line. That section must get stripped off because my
/bin/lsmod
doesn't have it. Anyway, here's the meat:
0280 01000000 01000001 2f746f6f 6c732f6c ......../tools/l
0290 69622f67 63632f69 3638362d 70632d6c ib/gcc/i686-pc-l
02a0 696e7578 2d676e75 2f342e31 2e312f69 inux-gnu/4.1.1/i
02b0 6e636c75 64650000 656c662d 696e6974 nclude..elf-init
02c0 2e630000 00007374 64646566 2e680001 .c....stddef.h..
So, there's a reference to the internal gcc include dir
from /tools in
the debugging information. IIRC, that happens with the way
the
toolchain get's built. It may be because the LFS toolchain
adjustment
doesn't do anything to the include dir path. I'm not sure.
I CC'd
Greg. Maybe he remembers more. Unfortunately, all my
binaries seem to
be stripped, so I can't see what's in their debugging
sections.
Greg, is this normal for the debugging info on the first
pass, or is
this a bug in LFS/JHALFS?
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page
|