>>>>> On Thu, 18 Feb 2010 18:43:04 +0100, Kern Sibbald said:
>
> On Thursday 18 February 2010 16:54:04 Martin Simmons wrote:
> > >>>>> On Wed, 10 Feb 2010 20:22:11 +0100, Kern Sibbald said:
> > >
> > > 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.
> >
> > I'm beginning to think that is the best default option :-)
>
> Sorry, but the default is going to remain to build shared libraries. We
> provide for users who want to turn it off.
>
> >
> > > > 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.
> >
> > Yes, it is too difficult to force Bacula's standards onto OS vendor
> > installations.
>
> I will give my recommendations, but it is Open Source, so they can do what
> they want. That is part of the beauty (and problems) of Open Source.
>
> >
> > > > 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.
> >
> > Yes, that's true (but I don't see any uses of LIBDIR in Bacula now).
> >
> > I think the problem with FreeBSD is that it sets
> >
> > LDFLAGS="-L${LOCALBASE}/lib"
> >
> > which puts -L/usr/local/lib before -L../lib -L../findlib in filed/Makefile
> > etc. That is probably needed to find readline etc, but it also causes ld
> > to find the old installed libs instead of the newly built ones.
>
> Yes, that is the problem.
>
> >
> > How about reordering the options? I.e. change
> >
> > $(LIBTOOL_LINK) $(CXX) $(WLDFLAGS) $(LDFLAGS) -L../lib -L../findlib -o $@
> > ...
>
> I am not planning to change the order of the flags. That always has created
> some problem on some system.
>
> >
> > to
> >
> > $(LIBTOOL_LINK) $(CXX) $(WLDFLAGS) -L../lib -L../findlib $(LDFLAGS) -o $@
> > ...
> >
> > etc for all of the makefiles.
> >
> > Alternatively, add a new variable LDLOPTIONS that is placed after -L../lib
> > -L../findlib in the makefiles.
>
> That is a possibility, but I don't think it will be necessary starting with
> version 5.0.1. We will look at it if necessary. In the mean time, Dan seems
> to have worked out building on FreeBSD.
Yes, Dan's solution is to tell builders to uninstall the old version first,
which will work.
The 5.0.1 fix helps for run-time problems after a correct build, so it does
some good.
Unfortunately it isn't going to fix build-time problems (assuming it is the
same as the current 5.1.0 git). The presence of -L/usr/local/lib will always
allow ld to find an old version of the libs in /usr/local/lib, because it
doesn't say "I want to link with 5.0.1 of this lib and 0.9.8l of that lib."
__Martin
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
