On Thu, 2009-08-20 at 15:18 +0200, Jan Friesse wrote:
> Fabio,
> when will libtool happened? I would like to have this feature + tool in
> Corosync 1.1.0.
I don't know. I think Jim started on this conversion. If necessary I can
take it over but it won't happen overnight.
> Is attached patch good solution of problem?
Unfortunately no because it will bump the soname for all libraries.
That's why we need a more fine graded control over them with libtools.
Fabio
>
> Regards,
> Honza
>
> Fabio M. Di Nitto napsal(a):
> > On Wed, 2009-08-19 at 21:57 -0700, Steven Dake wrote:
> >> On Thu, 2009-08-20 at 06:39 +0200, Fabio M. Di Nitto wrote:
> >>> This change the API and ABI for cpg.
> >>>
> >>> Before this change can go anywhere, it needs proper Makefile.am love or
> >>> even easier queue it after libtool changes that makes slightly easier to
> >>> have per library API and ABI versioning.
> >>>
> >>> Let's try, as a general rule, to avoid the same nightmare we had between
> >>> whitetank and current status with hidden API/ABI changes.
> >>>
> >>> Fabio
> >>>
> >> The addition of API calls are allowed in Y releases, and those additions
> >> don't result in a soname bump.
> >
> > I am not discussing if they are allowed or not. I know they are allowed.
> >
> >>>>> diff --git a/trunk/include/corosync/ipc_cpg.h
> >>>>> b/trunk/include/corosync/ipc_cpg.h
> >>>>> index 1d240d4..7df1891 100644
> >>>>> --- a/trunk/include/corosync/ipc_cpg.h
> >>>>> +++ b/trunk/include/corosync/ipc_cpg.h
> >>>>> @@ -45,6 +45,9 @@ enum req_cpg_types {
> >>>>> MESSAGE_REQ_CPG_MCAST = 2,
> >>>>> MESSAGE_REQ_CPG_MEMBERSHIP = 3,
> >>>>> MESSAGE_REQ_CPG_LOCAL_GET = 4,
> >>>>> + MESSAGE_REQ_CPG_ITERATIONINITIALIZE = 5,
> >>>>> + MESSAGE_REQ_CPG_ITERATIONNEXT = 6,
> >>>>> + MESSAGE_REQ_CPG_ITERATIONFINALIZE = 7
> >>>>> };
> >>>>>
> >>>>> enum res_cpg_types {
> >>>>> @@ -56,7 +59,10 @@ enum res_cpg_types {
> >>>>> MESSAGE_RES_CPG_DELIVER_CALLBACK = 5,
> >>>>> MESSAGE_RES_CPG_FLOW_CONTROL_STATE_SET = 6,
> >>>>> MESSAGE_RES_CPG_LOCAL_GET = 7,
> >>>>> - MESSAGE_RES_CPG_FLOWCONTROL_CALLBACK = 8
> >>>>> + MESSAGE_RES_CPG_FLOWCONTROL_CALLBACK = 8,
> >>>>> + MESSAGE_RES_CPG_ITERATIONINITIALIZE = 9,
> >>>>> + MESSAGE_RES_CPG_ITERATIONNEXT = 10,
> >>>>> + MESSAGE_RES_CPG_ITERATIONFINALIZE = 11,
> >>>>> };
> >
> >
> > ^^^ this is the problem.
> >
> > You are changing the internal API/ABI of the library towards the
> > executive/service.
> >
> > Unless you want to make sure that those values are totally optional,
> > then you need to bump the soname to make sure executive version that
> > handles those values is correctly linked against the correct version of
> > the library.
> >
> > See for example here:
> >
> > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
> >
> > ==== copy/paste ====
> >
> > When a new version of a library is binary-incompatible with the old one
> > the soname needs to change. In C, there are four basic reasons that a
> > library would cease to be binary compatible:
> >
> > 1. The behavior of a function changes so that it no longer meets
> > its original specification,
> >
> > 2. Exported data items change (exception: adding optional items to
> > the ends of structures is okay, as long as those structures are
> > only allocated within the library).
> >
> > 3. An exported function is removed.
> >
> > 4. The interface of an exported function changes.
> >
> >
> > If you can avoid these reasons, you can keep your libraries
> > binary-compatible. Said another way, you can keep your Application
> > Binary Interface (ABI) compatible if you avoid such changes. For
> > example, you might want to add new functions but not delete the old
> > ones. You can add items to structures but only if you can make sure that
> > old programs won't be sensitive to such changes by adding items only to
> > the end of the structure, only allowing the library (and not the
> > application) to allocate the structure, making the extra items optional
> > (or having the library fill them in), and so on. Watch out - you
> > probably can't expand structures if users are using them in arrays.
> >
> > ==== copy/paste ====
> >
> > By adding entries to the ipc, you are breaking ABI unless you are 100%
> > sure that an old version of cpg.lcrso will work just fine with the new
> > library and viceversa.
> >
> > Fabio
> >
>
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
