<br><br><div class="gmail_quote">On Sun, May 10, 2009 at 10:32 PM, Steve M. Robbins <span dir="ltr"><<a href="mailto:steve@sumost.ca">steve@sumost.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
<br>
On Tue, Apr 28, 2009 at 10:09:52AM -0400, David Cole wrote:<br>
> There are some API changes from VTK 5.2 to 5.4... Although there are not<br>
> many, I would still say the current dylib compatibility settings are<br>
> correct. The 5.4 dylibs cannot be loaded by a program built against 5.2 and<br>
> work flawlessly.<br>
><br>
> Some VTK 5.4 API changes are explicitly listed here:<br>
> <a href="http://www.vtk.org/Wiki/VTK_5.4_Release_Planning" target="_blank">http://www.vtk.org/Wiki/VTK_5.4_Release_Planning</a><br>
><br>
> And I would guess there are a handful of others that are simply not listed<br>
> anywhere, but would take source code analysis to uncover...<br>
><br>
> The dylib properties are set by the code in VTK's CMakeLists.txt that looks<br>
> like this:<br>
><br>
> # Append the library version information to the library target<br>
> # properties.  A parent project may set its own properties and/or may<br>
> # block this.<br>
> IF(NOT VTK_NO_LIBRARY_VERSION)<br>
>   SET(VTK_LIBRARY_PROPERTIES ${VTK_LIBRARY_PROPERTIES}<br>
>     VERSION "${VTK_VERSION}"<br>
>     SOVERSION "${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}"<br>
>     )<br>
> ENDIF(NOT VTK_NO_LIBRARY_VERSION)<br>
><br>
> The library VERSION property is the source of the dylib versions...<br>
<br>
</div>On unix/linux, SOVERSION is used to set ABI version.  Does<br>
"-compatibility_version" indicate the ABI version or API version?  If<br>
the former, then shouldn't it be set from SOVERSION rather than<br>
VERSION?<br>
<br>
Assuming we're talking about ABI (Application *Binary* Interface)<br>
version rather than API, recall that there are many ways to break<br>
binary compatibility even when API compatibility is maintained;<br>
e.g. add an instance variable to a class.  It's tough to audit for<br>
such changes, hence the conservative settings in CMakeLists.<br>
<br>
Regards,<br>
<font color="#888888">-Steve<br>
</font><div><div></div><div class="h5"><br>
</div></div></blockquote></div><br>This document is helpful:<br><a href="http://developer.apple.com/DOCUMENTATION/DeveloperTools/Conceptual/DynamicLibraries/index.html">http://developer.apple.com/DOCUMENTATION/DeveloperTools/Conceptual/DynamicLibraries/index.html</a><br>
<br>See also:<br><a href="http://people.redhat.com/drepper/goodpractice.pdf">http://people.redhat.com/drepper/goodpractice.pdf</a><br><a href="http://people.redhat.com/drepper/dsohowto.pdf">http://people.redhat.com/drepper/dsohowto.pdf</a><br>
<br>I am not entirely clear on whether -compatibility_version applies to ABI or API.  I was thinking API.  See the doc above for tips about exporting symbols (that controls the ABI?).<br><br>The <a href="http://apple.com">apple.com</a> document indicates that -compatibility_version is not checked for shared libs opened dynamically at run-time with dlopen; it does apply to dynamically linked libs.<br>
<br>Regards,<br>Darren<br><br>