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? ScottReceived on Tue Jan 17 2006 - 05:05:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC