/tools References in Binaries [Was Re: new makefile.]

Dan Nicholson dbn.lists at gmail.com
Wed Aug 30 07:16:18 PDT 2006

On 8/29/06, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On 8/29/06, George Boudreau <georgeb at linuxfromscratch.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?


More information about the alfs-discuss mailing list