On Wed, 2010-02-10 at 18:23 +0000, 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? Do they export an API that non-Bacula > programs can use? > First of all Bacula has shared libraries because is saves a lot of space on the dir, sd and fd (and all the tools) as instead of static linking the same code. The API is also usable for other programs but as stated the interface is not really to stable as things might change from version to version.
> 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. > That may work on some platforms but some have rather simplistic search ways which you either need to change using runtime linking flags or changing config files like ld.so.conf or setting things like LD_LIBRARY_PATH or using crle (on Solaris). > Kern's installation is like that already, because /opt/bacula/bin/bacula-dir > must be one specific version of Bacula at a time. Correct and things also work right if you specify a simple --prefix=/opt/bacula > > 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). > As stated above that may also be a packaging problem, I think the standard is /lib or /lib64 (for Linux x64) I don't know to much about FreeBSD but there might be a reason it packaged that way. > > > 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. Kern already pushed a change into GIT for both the master and 5.0 branch which sets the -release option of libtool (I must say I stopped reading to early in the libtool docs as it seems.) Then you get the following setup: libxx.so -> libxx.so.5.0.0 and so the binary is dependent on a specific version of the library (to be exact on a specific release) If we then bump the version on each release we are mostly save and in between versions are only for developers so we shouldn't be to concerned there as we can state you need keep your libs in sync with your new compiled binaries. The only things pending is then the removal of older versions but as stated before I see that really as a packaging thing. I was always wondering why the Bacula Makefiles have uninstall targets which you also don't see in to much OSS. Marco ------------------------------------------------------------------------------ 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
