On Thu, Aug 19, 2010 at 10:42:19AM +0900, Simon Horman wrote:
> On Wed, Aug 18, 2010 at 03:32:57PM +0200, Dejan Muhamedagic wrote:
> > On Wed, Aug 18, 2010 at 10:19:12PM +0900, Simon Horman wrote:
> > > On Wed, Aug 18, 2010 at 02:59:41PM +0200, Dejan Muhamedagic wrote:
> > > > On Wed, Aug 18, 2010 at 09:39:59PM +0900, Simon Horman wrote:
> > > > > On Wed, Aug 18, 2010 at 10:18:09AM +0200, Dejan Muhamedagic wrote:
> > >
> > > [snip]
> > >
> > > > > > Looking again at the whole matter, it is possible to run into
> > > > > > problems if one installs a pacemaker built against a new glue
> > > > > > release (>=1.0.5), but tries to run it with some older glue
> > > > > > release (<1.0.5). The reason is here (from
> > > > > > include/clplumbing/ipc.h):
> > > > > >
> > > > > > /* Unix domain socket with farside uid + gid credentials.
> > > > > > * Available since libplumb.so.2.1.0 */
> > > > > > #define IPC_UDS_CRED "uds_c"
> > > > > >
> > > > > > #ifdef IPC_UDS_CRED
> > > > > > # define IPC_ANYTYPE IPC_UDS_CRED
> > > > > > #else
> > > > > > # error "No IPC types defined(!)"
> > > > > > #endif
> > > > > >
> > > > > > uds_c didn't exist before. Before, IPC_ANYTYPE was defined to be
> > > > > > IPC_DOMAIN_SOCKET ("uds"). Must say that I don't know why that
> > > > > > changed. Users who needed "uds_c" should've asked for it
> > > > > > explicitely.
> > > > >
> > > > > In that case could I re-request that the so be bumped
> > > > > so we get libplumb.so.3.0.0 ?
> > > >
> > > > It has already been bumped to 2.1.0. Can't recall which version
> > > > it was before, perhaps 2.0.0. At any rate, if you deal only with
> > > > packages >= 1.0.5 you should be ok.
> > >
> > > If the change is incompatible I think that it would be correct
> > > to update current rather than the age. That way linking would
> > > fail and there wouldn't be any unexpected surprises after linking.
> > >
> > > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> >
> > As I wrote earlier, the -version-info was set to 3:0:0. For
> > whatever reason that resulted in libplumb.so.2.1.0.
>
> Hi Dejan,
>
> As it stands, -version-info info was changed from 2:0:0 to 3:0:1 in
> changeset 2384:c447fc25e119 "High: clplumbing: Fix ABI, bump libversion
> for: Add farside_uid and farside_gid info of the user on the other side of
> socket". As you point out produces libplumb.so.2.1.0. This ends up being
> symlinked to libplumb.so.2, which is likely what programmes link to.
>
> When -version-info was 2:0:0 libplumb.so.2.0.0 would have been produced
> which would also be symlinked to libplumb.so.2. So we are in a situation
> where there has been an incompatible ABI change but linking succeeds.
>
> My suggestion is that --version-info should be 3:0:0. That this
> would result in libplumb.so.3.0.0. That this would break linking,
> which is desirable as there has been an incompatible ABI change.
> And that its still desirable to do this for the next release.
>
> I have CCed Lars Ellenberg, who made the -version-info change to
> see if he has any thoughts.
The intention was to keep old stuff working even with new libs,
but have new stuff require new libs. If someone wanted to have
new stuff be able to talk with old libs, he would need to explicitly
only use the old features (read: explicitly use IPC_DOMAIN_SOCKET,
and make sure to not access the new struct members). This is unusual,
typically one would require users to use new features explicitly.
But because pacemaker is basically the only user of this stuff, it was expected
that if someone installs packages built against new headers, he would most
likely use the new features (pacemaker being the driving force for them), so
would need to install the new libs anyways. Thus I chose to do it this way
around.
In short, things compiled against the new headers (without explicitly taking
care to be backward compatible) should require libplumb.so.2.1, and all should
be well.
Changing that to require libplumb.so.3 instead does not improve things in any
way.
BTW, "debian" (I'm not sure from which repository) at some point in time had
available some 1.0.3-something taken more or less directly from mercurial at
that time, which already contained the ABI breakage,
but without any soname change, and without backward compatibility.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
