Solved: glibc-2.2.5 undefined _dl_cpuclock_offset

[Ingo Krabbe <i dot krabbe at dokom dot net>]

On Sunday, 12. May 2002 21:44, Andreas Jaeger wrote:
> Ingo Krabbe <i.krabbe@dokom.net> writes:
> > Hi,
> >
> > I've read the Ulrich Dreppers answers about mixing architectures but I
> > still cannot believe whats happening here:
> >
> > I have two systems on my hard disk.  I build a glibc into /glibc225 a new
> > gcc into /gcc and some binutils to /binutils.  When booting with one
> > system I get the
> >
> > /glibc225/lib/libpthread.so: undefined reference to `_dl_cpuclock_offset'
>
> Which dynamic linker is used?  Is the one from /glibc225/lib used?
> Use readelf to check for the path,
>
> Andreas
>
> > error.  I cannot reproduce that on the other system no matter how hard I
> > try !
> >
> > I will attach two outputs of
> > gcc -v main.c -lpthread &> out.err		-- for the problem
> > gcc -v main.c -lpthread &> out.good		-- for the good result
> >
> > which look quite the same with the difference that one throws the error. 
> > If anybody can tell what's different please tell me.  May it be the
> > kernel ???
> >
> > The working kernel says
> > Linux dimwit 2.4.18 #5 Mon Mai 13 14:37:25 CEST 2002 i686 unknown
> > the other one should be something like
> > Linux dimwit 2.5.15 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX athlon unknown
> >
> > To have the same configuration I linked in /glibc225 /gcc and /binutils
> > into both systems (different root disks).  And even copied the startfiles
> > /usr/lib/crt* from the bad one to the good one.
> >
> > Awaiting your words of wisdom ...

Wow, that was a real hard one:

I thought that `gcc -L/glibc225/lib main.c -lpthread' would be enough to link
against /glibc225/lib/libpthread.so.0. But that isn't so, at least it isn't
with new binutils package (You can get all version Numbers from the attachment
I made to the first E-mail of this thread).

Gcc actually links to what is contained in /lib/ld.so.cache I think, though
when using /glibc225/lib/ld-linux.so.2 gcc should use
/glibc225/etc/ld.so.cache, if it should link against a cache at all ?!

In my opinion the link phase shouldn't care about ld.so.cahce at all but 
honour
-L flags first and then take default paths into account.  It would also help 
if
such default paths would be contained in ld-linux.so.X, that the
-dynamic-linker option will also change these default paths.  But this whole 
stuff is binutils, not glibc.

The solution to my problem could be achieved by using `-rpath-link 
/glibc225/lib'.

I put this option directly behind the -dynamic-linker option in the compilers
specs file, that I needn't think about that anymore.  Hope I won't forget this
behaviour ;-)

That was nearly a day of annoying work ...  More luck to all of you out there 
...

BYE INGO