New malloc ready, take 42

John Baldwin jhb at freebsd.org
Fri Dec 23 06:24:07 PST 2005


On Friday 23 December 2005 08:35 am, Daniel Eischen wrote:
> On Fri, 23 Dec 2005, Daniel Eischen wrote:
> > On Fri, 23 Dec 2005, Scott Long wrote:
> > > Another thing that I worry about is complex library scenarios where you
> > > might have different versions of libc getting pulled into the same
> > > process by different library dependencies.  This could turn into a big
> > > headache that is only solvable by telling people to wipe out their
> > > entire ports collection and rebuild from scratch.  Does this warrant a
> > > library version bump now (as much as I really don't want to advocate
> > > this)?
> >
> > Please, no more library version bumps (ever, hopefully).  That's
> > what we have library versioning for.  Also, I don't see how
>
> I meant symbol versioning...
>
> > this changes external APIs (ABI) any more than we've done in
> > the past when adding interfaces.  We're adding posix_memalign()
> > and the __malloc_foofork() interfaces for our thread libraries.
>
> I think if you have more than one version of libc linked
> into your program, you might be hosed regardless of the
> malloc changes.  There's other global data in libc that
> may confuse the implementation when there is more than
> one instance of it.  Have we ever guaranteed that you could
> do that?

No, you're already screwed in that case.  This will only be potentially 
painful for folks using -current (since 7.0's libc will either be libc.so.7 
or have symbol versioning in use) and it's ok to create temporary pain for 
folks running -current.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-current mailing list