On Wed, Feb 10, 2010 at 10:00:57AM +0100, Kern Sibbald wrote: > OK, I think we are both on the same wavelength now. Thanks.
I don't think we were to much off though I probably already answered your questions below in the first email. > > 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: > > > Hello Marco, > > > > > > I think you have completely misunderstood the point of my email and the > > > problem I posed. > > > > I'm not sure I really understand the problem you are posing. I'm wondering > > if it is really a problem (I know it is for you but I didn't have time to > > have an indepth search into what and why) > > > > > I have no problem with changing the library version from 1 to 5, in fact, > > > it was I who suggested that you do it based on the Bacula version. This > > > was and is in my opinion the right thing to do. > > > > Sure it is but it has some impact. > > > > > 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. 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.) > > > > > > I was trying to explain that according to the new numbering scheme, > > > everything was correctly compiled and installed -- however, it left the > > > old 1.0.0 version of the shared objects installed. I expected that would > > > only use a bit of disk space, but in fact, having the old shared objects > > > installed in the same directory as the new shared objects prevented > > > Bacula from running -- or at least printed out the error messages I > > > pasted below. > > > > I must say that I don't understand this, as you ldd clearly shows it was > > linked against the 5.0.0 libs. I will copy my old 1.0.0 libs also in and > > see if I reproduce the behaviour. > > > > > This indicates to me that we are "missing" something -- at least I don't > > > yet understand what was going wrong. > > > > > > So bottom line: There are two new problems: > > > > > > 1. How to ensure that any old shared objects are removed when they should > > > be? > > > > I think this is a packaging problem, you could add some code to the install > > target of the Makefile but the whole idea is that you can have multiple > > major versions of a lib. Removing all other version of the libs kind of > > defeats that idea. > > > > > 2. Why does not Bacula run properly (or at least why does it print error > > > messages) when the old shared objects exist, and the new (re-numbered) > > > shared objects are properly installed? > > > > I'm not sure, I'm wondering if it wasn't just because the 5.0.0 libs were > > outdated. > > I rebuilt and re-installed them several times, so although they could have > been outdated, I don't see how, which is why this was a big mystery to me. For me too but I fail to get the same errors you are getting from placing the 1.0.0 libs back. > > > You said you removed all libs and then installed them again, I'm > > wondering if you removed the 1.0.0 version and tried again you would just > > get the same problems. > > Good question, I will run some tests here. Ok I will await the results from that then. I'm afraid we will never get a fault free versioning scheme for the libs unless we autoincrement things on every build which is also far from ideal. 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
