On Tue, 28 Aug 2007, Yar Tikhiy wrote: > On Sun, Aug 26, 2007 at 12:48:41PM -0400, Daniel Eischen wrote: >> >> Here it is on -current, feel free to redirect it to arch. >> >> I updated my notes on symbol versioning - see "Version naming conventions" >> on downwards at: >> >> http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt >> >> Feel free to cut&paste anything from it in replies. > > It seems that we've failed to divert the main discussion from the > cvs lists, so I'll comment on other sides of the symbol versioning > issue. > > First, you wrote that a symbol having multiple versions needs to > be listed in the symbol map file under each of its versions. I'm > afraid that the GNU ld(1) documentation doesn't suggest that. I > believe that it is correct to list each symbol in the symbol map > only once, under its default version. Ok, I'll update it. I think that part of my notes was written a long time ago. > Second, we need to decide how to handle SV consistently at source > tree level. In a trivial case, cut'n'paste or a stub function will > do, but in the more complex case of massive changes it can be hard > to reproduce the old ABI using stubs, e.g., because the new > implementation lost old bugs. In this case, CVS history should be > preserved for the old version at file level. A uniform approach > can be to repocopy the respective file(s) and add the version to > their name(s), e.g.: fts.c -> fts_fbsd_1_0.c. Does it sound > reasonable? Sure, I don't know if you have to use the version namespace in the filename, though. You could always put compat shim files into a separate directory too, but that might make building them a little more difficult if they rely on local headers. -- DEReceived on Tue Aug 28 2007 - 14:53:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC