On 08/14/2010 10:35 AM, Phil Dibowitz wrote: > On 08/14/2010 04:30 AM, Stephen Warren wrote: >> On 08/13/2010 01:27 AM, Phil Dibowitz wrote: >>> On 08/13/2010 04:40 AM, Stephen Warren wrote: >>>> On 08/12/2010 10:16 AM, Phil Dibowitz wrote: >>>>> On Thu, Aug 12, 2010 at 04:55:25PM +0100, Chris Mayo wrote: >>>>>> In 0.22 libconcord.py sets: ABI_VERSION = 2 >>>>>> causing it to look for libconcord.so.2 >>>>> >>>>> Crap. That should have gone 0 -> 1, not 0 -> 2. >>>>> >>>>> I have to release a 0.23 this weekend anyway, I'll fix that. >>>> >>>> I think it was originally 1 not 0. I don't think this value should have >>>> been changed at all, since when I build latest CVS, the link command >>>> includes: >>>> >>>> -Wl,-soname -Wl,libconcord.so.1 -o .libs/libconcord.so.1.1.0 >>>> >>>> ... and the Python bindings should be looking for the soname. >>> >>> I need to not talk from memory and look at the code. >>> >>> OK, it should be 2, because the so-version should be 2.0.1: >>> >>> -libconcord_la_LDFLAGS = -version-info 1:0:0 -lusb >>> +libconcord_la_LDFLAGS = -version-info 2:0:1 -lusb >>> >>> I bumped the version due to the change in API. >>> >>> However, I misunderstood how that gets put into a final version number. >>> >>> Since this says we are version 2, but support 1 previous version, the >>> so-version changed from 1.0.0 to 1.1.0. If I'd made this 2:0:0, then it >>> would have been 2.0.0. >>> >>> So the so-version changed, but sorta not in the way I expected. >>> >>> So really what we want is ABI_VERSION = 1.1, though I don't know if python >>> supports non-integers there. I have to get to work, I'll look into it >>> tonight. >> >> You could make this a string and it'd work fine. >> >> However, 1.1 isn't the correct value; libconcord currently installs the >> following: > > 1.1.0 would technically be correct. It will be depending on the extra calls > in 1.1.0. > > I've set it to that in CVS. Is that reasonable?
No, that's not correct; it should be "1" given the current libconcord.so settings. If you run ldd on the concordance application, you'll see that it searches for "libconcord.so.1" (the soname), which is then symlinked to "libconcord.so.1.1.0" (the current implementation of that soname). The Python bindings should be searching for the soname too just like the concordance application. However, since the ABI changed, this should really be "libconcord.so.2". Without that change, a concordance application built from the latest source will still be looking for libconcord.so.1, which could be satisfied by a libconcord built from either new or old sources (since they have the same soname and filenames), yet a libconcord built from old sources wouldn't work with the latest concordance application because of the missing functions. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
