From owner-freebsd-current@FreeBSD.ORG Tue Jan 17 06:05:27 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 06BCF16A41F; Tue, 17 Jan 2006 06:05:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4781243D45; Tue, 17 Jan 2006 06:05:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0H65LsS064530; Mon, 16 Jan 2006 23:05:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43CC8925.40007@samsco.org> Date: Mon, 16 Jan 2006 23:05:25 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <43CC877D.2070603@samsco.org> In-Reply-To: <43CC877D.2070603@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Daniel Eischen , current@freebsd.org Subject: Re: New malloc breaks old libpthread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:05:27 -0000 Scott Long wrote: > Daniel Eischen wrote: > >> On Mon, 16 Jan 2006, Doug White wrote: >> >> >>> Got this trying to run an old Xorg binary on a -CURRENT machine I don't >>> update very frequently: >>> >>> /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol >>> "__malloc_lock" >>> >>> The libpthread.so.1 was from June 2005, prior to the libpthread version >>> bump. Unfortunately this means that RELENG_6 compatibility is broken in >>> -HEAD since the new libc.so.6 is not compatible with libraries built >>> against it prior to the merge date of the new user malloc. >> >> >> >> Don't do that. We don't guarantee -current libraries built on >> (vastly) different dates will run nicely together. >> >> >>> 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? > > Scott > Gahh, fingers fell asleep in mid-sentence, let me try that again.... .... is there a set procedure that one must follow when introducing incompatibilities? Scott