Date: Sun, 14 May 2000 02:52:49 -0400 (EDT)
From: Roland McGrath <[EMAIL PROTECTED]>
> On Sat, Apr 22, 2000 at 02:20:30AM +0200, Marcus Brinkmann wrote:
> >
> > I have troble with current CVS version, cross compiled with gcc
> > 2.95.2 and glibc 2.1.3 (as of 2000/02/24). When booting, I get:
The changes I made related to versioning went into glibc (2.2) on
2000-03-30 or thereabouts and into hurd/libthreads at about the same time.
It is not too surprising to have a problem with an old glibc and a new
hurd. I am not able to do any real hacking or even much code-reading these
days (it will be probably at least several more weeks before I can), and I
don't recall the full details of all this off hand. I don't think there
should be a problem like this, but I don't have enough information on hand
right now to be of much more help. Mark understands the details too and
might be able to help before I can.
There is indeed a versioning problem. The following symbols exist
both in libc and libthreads:
__mutex_lock_solid, __mutex_unlock_solid,
_cthread_exit_routine, _cthread_init_routine,
cthread_keycreate, cthread_getspecific, cthread_setspecific;
The symbols in libc are supposed to overridden by the symbols in
libthread. Before Roland's change, the symbols in libc were're bound
to version GLIBC_2.0, and the symbols in libthreads were unversioned,
and apparently this worked fine. However, now the symbols in
libthreads are versioned, and bound to a *different* version
HURD_CTHREADS_0.3. So the symbols in libthread no longer override
those in libc. This means that the cthreads library isn't initialized
so it isn't surprising that the exec server crashes in the boot
process.
I think Roland's nifty versioning plan can only be implemented if we
use different versions for a libio-ified Hurd than for a stdio-using
Hurd. In that case I think it is reasonable to keep libthreads
unversioned with stdio and only use the version script with libio.
If you agree Roland, I'll add the necessary stuff to configure.in and
the relevant Makefile.
Mark
