On Saturday 25 August 2007 01:06:37 am Yar Tikhiy wrote: > On Fri, Aug 24, 2007 at 06:25:17PM -0400, Daniel Eischen wrote: > > I never added symbol versioning to libc in order to solve > > -current upgrade problems. Sure, you're free to use it that > > way, but it would not make me very happy ;-) > > You put it as though symbol versioning is your area of interest and > you just don't want any intruders to tamper with it. It wouldn't > have seemed so if there had been a well-defined policy on symbol > versioning usage somewhere on www.freebsd.org.
No, there isn't a well-defined policy currently, feel free to write it down. :) What Dan is saying is that symbol versioning should follow the same de facto policy used prior to symbol versioning for managing shared library major numbers which is: only bump once during HEAD even if you have multiple ABI changes. Otherwise you can stifle work on HEAD as people will have to provide compat every time they change an ABI in HEAD even if they change it 3 or 4 times before the X.0 release. HEAD only needs to retain compat for earlier RELENG_x, it has never and should not contain compat for older HEAD except as temporary hacks. You also have the issue of adding a lot more compat clutter to the libraries if we support compat for every ABI change that ever happens in HEAD. In this case using a fbsd.hack symbol version for the old fts(3) symbols won't work, the existing binaries are already linked against fbsd-1.0, but the new fts(3) routines should be fbsd-1.0 as fbsd-1.0 is already a version bump from RELENG_6 (libc.so.6 and no symbol versions). -- John Baldwin _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
