On Friday 23 December 2005 08:35 am, Daniel Eischen wrote: > On Fri, 23 Dec 2005, Daniel Eischen wrote: > > On Fri, 23 Dec 2005, Scott Long wrote: > > > Another thing that I worry about is complex library scenarios where you > > > might have different versions of libc getting pulled into the same > > > process by different library dependencies. This could turn into a big > > > headache that is only solvable by telling people to wipe out their > > > entire ports collection and rebuild from scratch. Does this warrant a > > > library version bump now (as much as I really don't want to advocate > > > this)? > > > > Please, no more library version bumps (ever, hopefully). That's > > what we have library versioning for. Also, I don't see how > > I meant symbol versioning... > > > this changes external APIs (ABI) any more than we've done in > > the past when adding interfaces. We're adding posix_memalign() > > and the __malloc_foofork() interfaces for our thread libraries. > > I think if you have more than one version of libc linked > into your program, you might be hosed regardless of the > malloc changes. There's other global data in libc that > may confuse the implementation when there is more than > one instance of it. Have we ever guaranteed that you could > do that? No, you're already screwed in that case. This will only be potentially painful for folks using -current (since 7.0's libc will either be libc.so.7 or have symbol versioning in use) and it's ok to create temporary pain for folks running -current. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Fri Dec 23 2005 - 13:24:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:49 UTC