Re: [Libusb-devel] Darwin dylibs always marked version 1.0.0

[Orin E. <ori...@gm...>]

On Wed, Sep 29, 2010 at 9:14 AM, Ludovic Rousseau <
lud...@gm...> wrote:

> 2010/9/29 Daniel Drake <da...@re...>:
>  > El 29/09/10 11:57, Daniel Drake escribió:
> >>
> >> El 29/09/10 10:57, Ludovic Rousseau escribió:
> >>>
> >>> Some documentation about libtool versioning is available at:
> >>>
> >>>
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> >>> http://sourceware.org/autobook/autobook/autobook_91.html
> >>
> >> This is certainly something I should have been doing but haven't.
> >> So for the next release I think we want this:
> >>
> >> # Programs using the previous version may use the new version as drop-in
> >> replacement, but programs using the new version may use APIs not present
> >> in the previous one. In other words, a program linking against the new
> >> version may fail with “unresolved symbols” if linking against the old
> >> version at runtime: set revision to 0, bump current and age.
> >>
> >> This is due to the addition of libusb_strerror (or any of the other
> >> additions made since 1.0.0 if you want to look at it that way)
> >>
> >> In other words: 1:0:1
> >>
> >> We already have this in configure.ac:
> >> # Library versioning
> >> lt_major="0"
> >> lt_revision="0"
> >> lt_age="0"
> >> AC_SUBST(lt_major)
> >> AC_SUBST(lt_revision)
> >> AC_SUBST(lt_age)
> >>
> >> But it looks like I've never changed the numbers nor hooked it up to the
> >> linkage in the build.
> >>
> >> I'm clear on this on the linux/libtool front now.
> >> But do the same rules apply for Mac?
> >
> > Looks like they do.
> >
> > In both cases, libtool takes the numbers and looks at the host OS
> > technicalities in order to produce the final library filename - in
> neither
> > case it is a direct copy of the numbers that you pass to -version-info
> >
> > Here's what happens on darwin:
> > http://lists.apple.com/archives/darwin-dev/2005/Apr/msg00063.html
> >
> > So, I think the attached patch is what we want, followed by strict
> following
> > of the libtool rules on future releases.
> > Thoughts?
>
> WIth the patch I have (on Mac OS X):
>
> $ otool -L /tmp/libusb/usr/local/lib/libusb-1.0.dylib
> /tmp/libusb/usr/local/lib/libusb-1.0.dylib:
>        /usr/local/lib/libusb-1.0.0.dylib (compatibility version 2.0.0,
> current version 2.0.0)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 125.2.0)
>
> The compatibility version is 2.0.0 so the library can't be used by
> programs linked with a previous version. Is that desired?
>



I thought it worked the other way around - programs linked against
compatibility version 2.0.0 can't load compatibility version 1.0.0 which is
what we want.  Current version is just informational from what I could tell
from http://www.finkproject.org/doc/porting/porting.en.html:

<<The "current" version is for informational purposes only. The
"compatibility" version is used for checking as follows. When an executable
is linked, the version information from the library is copied into the
executable. When that executable is run, the stored version information is
checked against the version information in the library that is loaded. dyld
generates a run-time error and terminates the program unless the loaded
library version is equal to or newer than the one used during linking.>>



I think if we follow the rules in
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html,
everything should be fine.

I'll reiterate what Peter says in another message that these version numbers
are ABI versions and do not match the external library release number.
Orin.