On 04/05/2010 20:41, Peter Rosin wrote:
Den 2010-05-04 20:00 skrev Ralf Wildenhues:
Errrm, is that really so? I tend to agree with Jef here...
I take it that your response is to my "... it will work" sentence, not
the paragraph below that.
Ah, indeed.
The algorithm *could* be interpreted such that e.g. the interface
change
"int foo(void)" -> "int foo(int)" is an interface addition of int
foo(int)
and an interface remove of int foo(void), thus triggering both #5
and #6.
But in that case "changed" need not be mentioned in #4 either. So,
because
"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.
Ah, ok. Yes, you're right. Feel free to commit a patch to
s/removed/& or changed/ in 6.
Sorry I came in late for the discussion. Is it correct to interpret
"removed" as an interface has been removed, or an interface has been
changed so as to cause a binary incompatibility, so that bumping the
major version is the result to indicate it is not 100% binary compatible
with the previous version, and therefore may break a program that is
already compiled against this library?
I've pushed the attached patch...
Cheers,
Peter
2010-05-05 Peter Rosin <p...@lysator.liu.se>
Clarify versioning algorithm documentation.
* doc/libtool.texi (Updating version info): Be explicit
about setting age to zero on interface change.
Reported by Jef Driesen <jefdrie...@hotmail.com>
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
