Source version should be sufficient to identify a library, so long as API functions or variables aren't removed within an BOINC major version number. The current source should produce libboinc_api.so.7.5.0 aka libboinc_api.so.7.5 aka libboinc_api.so.7
Hopefully we aren't removing existing functions, so an app linked with libboinc_api.so.7.0.0 might be OK with libboinc_api.so.7.5.0 . (I don't recall when boinc_ops_cumulative() was removed. It could have been replaced with an empty function rather than removed.) On Wed, Jun 18, 2014 at 4:10 PM, Richard Haselgrove < [email protected]> wrote: > This would presumably require the discipline that the libraries are > strongly versioned, so that they can be unambiguously identified? > > We do that for the client now, but not for server code (since we lost the > 'server stable' designation). Where does the API stand on that spectrum? > > ------------------------------ > *From:* Eric J Korpela <[email protected]> > *To:* David Anderson <[email protected]> > *Cc:* "[email protected]" <[email protected]>; > Gianfranco Costamagna <[email protected]> > *Sent:* Thursday, 19 June 2014, 0:07 > *Subject:* Re: [boinc_dev] Boinc and shared dynamic libraries > > Under package management, there can be version dependency between the > applications and libraries, so if new libraries are deployed, a new > application would be deployed at the same time, if necessary. Or not, if > its not necessary. > > > On Wed, Jun 18, 2014 at 2:59 PM, David Anderson <[email protected]> > wrote: > > > I still don't see this. > > The BOINC API evolves constantly. > > If it were included with the BOINC client as a dynamic library, > > an app would get a potentially old version - > > possibly buggy, possibly missing a required feature. > > That would make debugging apps even harder than it already is. > > > > > > On 18-Jun-2014 8:38 AM, Eric J Korpela wrote: > > > >> > >> > >> > >> On Tue, Jun 17, 2014 at 9:07 PM, David Anderson <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> What's the reason for using dynamic libraries in the client? > >> And how does this relate to applications? > >> -- David > >> > >> > >> Many linux (and BSD/Solaris/Other) package distributions strongly > >> encourage or even > >> demand shared libraries for any package that might be shared. It > >> doesn't affect > >> clients distributed by the projects at all. But since the open source > >> applications > >> (SETI@home) are distributed as packages in by some repositories, they > >> will share the > >> API and graphics API library and (in the case of SETI@home) will > >> probably use the > >> shared system version of FFTW. > >> > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
