Date: Mon, 16 Jan 2006 22:58:21 -0700 From: Scott Long <scottl@samsco.org> To: Daniel Eischen <deischen@freebsd.org> Cc: current@freebsd.org Subject: Re: New malloc breaks old libpthread Message-ID: <43CC877D.2070603@samsco.org> In-Reply-To: <Pine.GSO.4.43.0601170051260.10462-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0601170051260.10462-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43CC877D.2070603>