Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 17:10:54 +0100:
> Hi Daniel,
> > If we backport your unlock_prompt_func patches to 1.7.3, someone
> > downgrading the bindings from 1.7.3 to 1.7.2 will get runtime linker
> > errors, correct? If so we cannot backport it.
> I think that will not happen, since the C function is defined in the
> bindings, not in the main subversion libraries. In other words, the C
> code required is included with the bindings (so there's even three
> versions of the function, one for each binding), so downgrading the
> bindings removes the py/pl/rb function as well as the C function
> wrapped. The C function itself only uses pre-existing stuff in the main
> subversion libraries, so that should not cause any problems either.
% find $prefix/lib/svn-python | egrep 'core'
So, you are saying that there is no legitimate/supported scenario in
which the .py and .so are out of sync with each other? And that code
written for a library version that has the symbol will return a normal
error (eg, AttributeError in Python) when run against a library version
(such as 1.7.2) that doesn't have the symbol?
(I'm talking about the .so here; it's not clear to me whether your
reference to hasattr() checked the existence of the symbol in the .py
library file or in the .so library file.)
In these cases it seems to me that we might be able to backport this.
> I just did some tests with the python example: When doing a "make
> install" from the latesst tree and "make install-swig-py" from a 1241553
> tree (before my patch was added), I get no linker errors (but I don't
> get a prompt either, the hasattr() call in the example can detect the
> absence of the function just fine [or an AttributeError would be called
> When doing it the other way around (old main libraries with new
> bindings), everything works fine, I even get the prompt.
Received on 2012-02-08 18:02:33 CET