From owner-freebsd-current@FreeBSD.ORG Tue Jan 17 06:13:54 2006 Return-Path: X-Original-To: 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 76C3016A420 for ; Tue, 17 Jan 2006 06:13:54 +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 A46F843D70 for ; Tue, 17 Jan 2006 06:13:52 +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 k0H6DpeV014314; Tue, 17 Jan 2006 01:13:51 -0500 (EST) Date: Tue, 17 Jan 2006 01:13:51 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <43CC877D.2070603@samsco.org> 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: current@freebsd.org Subject: Re: New malloc breaks old libpthread 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: Tue, 17 Jan 2006 06:13:54 -0000 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