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.
Best regards,
Kern
>
> __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
