[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem compiling (gcc? glibc?)

On Fri, Jan 21, 2005 at 10:54:44AM +1300, Andrew Walbran wrote:
> On Mon, 17 Jan 2005 1:23 pm, David wrote:

> > IIUC, how the ld library thing works is that all "optional" search path
> > are searched for unresolved references and finally /lib itself is
> > searched.  Perhaps there are some unresolved references in the /lib/tls/
> > directory that are supposed to finally get resolved in the /lib
> > directory (or some other)  and for some reason his system is not
> > searching there.

> It seems to me that for some reason ld-linux and gcc have different ideas of 
> where to look. Dynamic linking apparently works at runtime (if it didn't no 
> programs would run) but gcc thinks that there are undefined references.

Yes, this seems to be the correct assumption.  Are there any
configuration files for gcc that might cause this?  It seems that gcc is
stopping short in doing the library searches.  Have you tried something
like this?

(export IFS=:; for i in `gcc -print-search-dirs`; do echo $i; done)


> > To Andrew:
> >
> > You might run gcc on a source, and get some names of references that
> > don't get resolved and then try to find where they are found in your
> > library.  It may be tedious, but the tool to use, I'd think, would be
> > objdump.
> I'm not quite sure what you mean. Could you please elaborate?

Actually, this is not really productive, I don't think.  What I was
suggesting was to run gcc and get some names of these undefined
references and then search for these references in the libraries.  But
this would probably be a waste of time.

> Incidently, running ldd -r on either /lib/libc.so.6 or /lib/tls/libc.so.6 
> reports no undefined references.

Hmm.. when I run ldd -r, all I get is
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Reply to: