New malloc ready, take 42
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