OK, I think we are both on the same wavelength now. Thanks. 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. > > > 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. > 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. Best 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
