This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Solved: glibc-2.2.5 undefined _dl_cpuclock_offset
- From: Ingo Krabbe <i dot krabbe at dokom dot net>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 14 May 2002 01:38:04 +0200
- Subject: Solved: glibc-2.2.5 undefined _dl_cpuclock_offset
- Organization: ask (automatische system komponenten)
- References: <E176yQi-0005RX-00@mail.dokom.net> <u8znz59mnm.fsf@gromit.moeb>
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