On 2010-08-29 Doug Barton <[email protected]> wrote: > On 08/29/2010 09:29 AM, Andreas Metzler wrote: >> You are already supposed to "change those numbers" (if you make a >> release).
> The only time you should change the library version number(s) is if the > ABI changes. I completely and totally agree that changinging the soname without good reason must not be done. > In other words, if a program that was linked against the > old library will not run if linked against the new one. > Gratuitously changing the library version number(s) creates an enormous > headache for everyone who packages the code. With "these numbers" I was refering to libtools versioning scheme (current:revision:age). If they are (only) changed according to libtool's documentation the right thing happens. - The soname is only changed on ABI breakage. > As for symbol versioning, it can be useful, but is probably overkill for > something like libwraster unless there are plans to change its internals > dramatically down the road. I do agree that not exporting private > symbols is a good idea. My point was that the only simple way I know of to stop the unwanted export was to add a linker script listing the to-be-exported symbols. If one does this, versioning is (almost) zero additional effort. > As for where to keep the library version numbers the usual way is to > keep them as #define's in the code. That way if people are doing things > with the code not related to auto* they don't get the dreaded > "unpredictable results." [...] Could you point me to an example library? The ones I am familiar with keep the libtool version string in either Makefile.am or configure.ac. thanks, cu andreas -- To unsubscribe, send mail to [email protected].
