On Wednesday 10 February 2010 19:23:01 Martin Simmons wrote: > >>>>> On Wed, 10 Feb 2010 11:03:46 +0100, Marco van Wieringen said: > > > > > > See comments below ... > > > > > > On Wednesday 10 February 2010 09:48:38 Marco van Wieringen wrote: > > > > On Wed, Feb 10, 2010 at 08:28:25AM +0100, Kern Sibbald wrote: > > > > > The problem is that for some reason changing the version (all > > > > > components were changed correctly and installed correctly) did not > > > > > resolve the problem but in fact created a whole new problem which > > > > > is the complete failure of Bacula to be able to run. > > > > > > > > As I explained in the previous mail changing the major number only > > > > fixes one specific problem and that is you can have both Bacula > > > > Enterprise Edition and the Community edition on one server. But > > > > symbol changes are still a problem. > > > > > > My primary interest was not being able to run two versions, which I > > > think very few people do (except perhaps developers). My main interest > > > was to ensure that the libraries that Bacula uses are the correct ones > > > (i.e. that we don't have two different libraries that are identically > > > named) so that we could avoid build errors when users supply incorrect > > > extra libraries due to older previously installed incompatible versions > > > as we saw in one case. > > > > Ok and I have said it before and I say it again its rather tricky todo > > that. > > Why does Bacula have shared libraries?
Because each of the daemons use the libraries (not all use every library) and each of the tools use one or more of the libraries. You can always turn off building shared libraries. > Do they export an API that non-Bacula programs can use? We have not explicitly documented the interfaces to the libraries, but some users are amazingly enough using our shared libraries. I suspect that over time we will fix many of the interfaces (calling sequences) and publish them. > > If the libraries are only used by the Bacula "family" of programs (maybe > including bat), then I suggest always installing them in a Bacula-specific > directory. You can then give it a version-specific name if needed. Unfortunately, we do not have control over where users install their binaries or libraries. We supply a configuration option that permits placing the shared objects where you want, and the recommendations of the project are to install virtually all of Bacula's files (exception for doc, man pages, ...) in a single directory /opt/bacula. This is largely ignored. > > Kern's installation is like that already, because > /opt/bacula/bin/bacula-dir must be one specific version of Bacula at a > time. > > That would also solve a problem on FreeBSD, where the old version libs are > installed in /usr/local/lib, which is also on the search path for libs when > a new version is built (possibly the "one case" that Kern referred to > above). In the case you mention above, the "user" explicitly set LIBDIR if I remember right, and that probably caused the problem. If one uses ./configure without overriding Bacula generally works fine. > > > We then need to increase the major number of the libraries with each > > release we do. Which is doable (e.g. we increase it when we start on a > > new branch) as with c++ with every change you do to the definition of > > functions in the source the symbols change in the shared lib. I guess it > > doesn't make sense to upgrade the version all the time doing a > > development cycle. If you look at the way the numbering is done with > > libtool the major (first digit) changes on each interface change (that is > > why the libtool states don't change your interfaces to much) but for us > > that is not really an option. I think that we have however the same > > problem with plugins (ok the interface might not change to much there but > > the arguments to a plugin might.) > > Perhaps you can number them in a recognisable way too? E.g. 500 for > version 5.0.0 etc. We have switched from using libtool -version-tool to using -release, which means if the current code works as we expect, we will release version 5.0.1 with libraries either versioned as 5.0.0 or 5.0.1 Regards, Kern ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
