Re: New malloc breaks old libpthread

On Mon, 16 Jan 2006, Scott Long wrote:

> Daniel Eischen wrote:
> > On Mon, 16 Jan 2006, Doug White wrote:
> >
> >>I guess its time libc's version number.  We haven't yet for post-RELENG_6,
> >>and this it the usual case calling for the bump.
> >
> >
> > No.  There's no need -- this is -current, and we have symbol versioning
> > now anyways.
>
> So.......
>
> How exactly does symbol versioning help this case?  It obviously doesn't
> magically make all problems go away, so is there a set procude that
> one must follow when introducing incompatibilities?  If there is a
> procedure, is it published anywhere?

We haven't yet done this, so no, there is no procedure.  But the tools
should be in place.  You can see how to create a symbol map file from
libpthread's example (src/lib/libpthread/pthread.map).

I'm no expert at this (I think kan originated pthread.map for libpthread),
but I suspect you just need to duplicate what was done for libpthread.
For binary compat, you need to keep the old malloc_lock around in the
new libc but under an old version identifier (you will probably have
to keep old malloc behavior in regard to this lock also, but only
for the older symbol version).

Our libc currently doesn't have symbol versioning information, so I
don't know if this will work until binaries have been initially built
with version info.

kan's probably the guy to ask for details.

-- 
DE