Date: Fri, 23 Dec 2005 08:35:01 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org, Jason Evans <jasone@freebsd.org> Subject: Re: New malloc ready, take 42 Message-ID: <Pine.GSO.4.43.0512230828110.28572-100000@sea.ntplx.net> In-Reply-To: <Pine.GSO.4.43.0512230815590.28572-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0512230828110.28572-100000>