From: <jb...@ac...> - 2011-08-31 06:16:16
|
From: Andreas Kleinert [mailto:in...@ar...] >I've found an interesting article/discussion on the matter, which brings up some other aspects: >http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols I didn't think it was meant to work that way. I thought that if the ABI of a function did not change then the version number of that function should not change either, even if the version of the library has to change because of an API change in some *other* function. This is potentially useful to libpng: we hardly ever change the API, and, if png_struct and png_info are invisible, that means we don't change the ABI. Of course if we have to change the version of png_create_read_struct, etc, then all the ABIs change, but that hasn't (I think) ever happened! Now I think the glibc guys may well be doing something different and trying for a much more fine-grained definition of 'version' which, as the discussion points out, is not particularly useful and may be harmful. >(*) i.e. IMHO it's much easier to do something like that > > if(libversion > 2) // for some function/struct which changed > { That seems to assume that there are at least two versions of png_struct possible in a single executable (including libpng.so), which means there are two versions of png_create_read_struct in the library, which, I think, is where the problems start. In fact we do what I was talking about already, the libpng poor man's versioning, which consists of pretty much never changing the ABI but inventing new functions instead, possibly deprecating then removing the previous function. I suspect this approach is adequate, easier to understand, works everywhere and is almost infinitely easier to maintain: maybe I don't understand why anyone wants symbol versioning. Is someone trying to build composite libpng libraries (all versions in one DLL?) John Bowler <jb...@ac...> |