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