Sorry I haven't responded sooner, awfully busy lately.
On 8/30/2010 10:01 AM, Andreas Metzler wrote:
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.
Glad we agree on that, and if I misunderstood the original proposal my
apologies.
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.
Hrrrm, well, ok. I have had bad experiences with libtool on other
projects, so my default reaction is "let sleeping dogs lie." But you
sound like you know what you're doing. :)
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.
I'm not worried about the additional effort, I'm worried about
additional complexity down the road. Although with your message today it
sounds like you've got an idea of how to proceed, so I'll leave you to it.
Doug
--
To unsubscribe, send mail to [email protected].
