>>>>> 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? Do they export an API that non-Bacula programs can use? 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. 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). > 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. __Martin ------------------------------------------------------------------------------ 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
