From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:35:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C3A16A420; Fri, 23 Dec 2005 13:35:04 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E07343D5F; Fri, 23 Dec 2005 13:35:03 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jBNDZ2Th022130; Fri, 23 Dec 2005 08:35:02 -0500 (EST) Date: Fri, 23 Dec 2005 08:35:01 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org, Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 13:35:04 -0000 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