bacula-devel

[Bacula-devel] Problem installing Bacula

[Kern S. <ke...@si...>]

Hello Marco,

Unfortunately, something is not working totally correctly with Bacula 
installation with shared libraries.  I ran into a problem where everything 
was failing after your patch to update to use .so.5 instead of .so.1

What I ended up in my lib installation directory was stuff like:

libbacsql.la
lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so -> 
libbacsql.so.5.0.0
lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so.5 -> 
libbacsql.so.5.0.0
-rwxr-xr-- 1 kern kern  420362 2010-02-09 14:00 libbacsql.so.5.0.0

Plus:

libbacsql.so.1.0.0

which was left over from a prior install.  Now, one would normally think that 
everything would work correctly.  Here is a listing of what bacula-dir 
wanted:

ldd bacula-dir
        linux-gate.so.1 =>  (0xb7f1f000)
        libbacfind.so.5 => /opt/bacula/lib/libbacfind.so.5 (0xb7f10000)
        libbacsql.so.5 => /opt/bacula/lib/libbacsql.so.5 (0xb7eed000)
        libbacpy.so.5 => /opt/bacula/lib/libbacpy.so.5 (0xb7eea000)
        libbaccfg.so.5 => /opt/bacula/lib/libbaccfg.so.5 (0xb7ee3000)
        libbac.so.5 => /opt/bacula/lib/libbac.so.5 (0xb7e92000)
        libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0xb7c99000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7c67000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7c4e000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7c39000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c21000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c1d000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7bdb000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 
(0xb7a99000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb79a5000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7980000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7975000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7826000)
        /lib/ld-linux.so.2 (0xb7f20000)

all that looks perfectly fine.  In principle, the extra libbacsql.so.1.0.0, 
should not harm anything, but when I execute bacula-dir, I get:

Starting the Bacula Director daemon
/opt/bacula/bin/bacula-dir: Symbol `uar_create_temp1' has different size in 
shared object, consider re-linking
/opt/bacula/bin/bacula-dir: Symbol `create_deltabs' has different size in 
shared object, consider re-linking
/opt/bacula/bin/bacula-dir: Symbol `uar_file' has different size in shared 
object, consider re-linking
/opt/bacula/bin/bacula-dir: Symbol `uar_create_temp' has different size in 
shared object, consider re-linking
/opt/bacula/bin/bacula-dir: Symbol `uar_jobid_fileindex_from_dir' has 
different size in shared object, consider re-linking

The solution is very simple in my case, just delete everything from lib 
(single file Bacula install) and redo make install, and all works, but on a 
standard system where .so files are installed in /usr/lib, it is much more 
complicated.

Do you have any idea what went wrong and how to correct it?

Best regards,

Kern

Re: [Bacula-devel] Problem installing Bacula

[Marco v. W. <mv...@pl...>]

On Tue, 2010-02-09 at 14:18 +0100, Kern Sibbald wrote:
> Hello Marco,
> 
> Unfortunately, something is not working totally correctly with Bacula 
> installation with shared libraries.  I ran into a problem where everything 
> was failing after your patch to update to use .so.5 instead of .so.1
> 
Ok that doesn't sound to good.

> What I ended up in my lib installation directory was stuff like:
> 
> libbacsql.la
> lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so -> 
> libbacsql.so.5.0.0
> lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so.5 -> 
> libbacsql.so.5.0.0
> -rwxr-xr-- 1 kern kern  420362 2010-02-09 14:00 libbacsql.so.5.0.0
> 
> Plus:
> 
> libbacsql.so.1.0.0
> 
Ok that could be because I forgot to change the cats version to 5.0.0
and only changed the other 4 libs in the first patch.

> which was left over from a prior install.  Now, one would normally think that 
> everything would work correctly.  Here is a listing of what bacula-dir 
> wanted:
> 
> ldd bacula-dir
>         linux-gate.so.1 =>  (0xb7f1f000)
>         libbacfind.so.5 => /opt/bacula/lib/libbacfind.so.5 (0xb7f10000)
>         libbacsql.so.5 => /opt/bacula/lib/libbacsql.so.5 (0xb7eed000)
>         libbacpy.so.5 => /opt/bacula/lib/libbacpy.so.5 (0xb7eea000)
>         libbaccfg.so.5 => /opt/bacula/lib/libbaccfg.so.5 (0xb7ee3000)
>         libbac.so.5 => /opt/bacula/lib/libbac.so.5 (0xb7e92000)
>         libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0xb7c99000)
>         libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7c67000)
>         libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7c4e000)
>         libz.so.1 => /usr/lib/libz.so.1 (0xb7c39000)
>         libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c21000)
>         libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c1d000)
>         libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7bdb000)
>         libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 
> (0xb7a99000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb79a5000)
>         libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7980000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7975000)
>         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7826000)
>         /lib/ld-linux.so.2 (0xb7f20000)
> 
> all that looks perfectly fine.  In principle, the extra libbacsql.so.1.0.0, 
> should not harm anything, but when I execute bacula-dir, I get:
> 
Ok it has linked in all .so.5 versions so that looks ok.

> Starting the Bacula Director daemon
> /opt/bacula/bin/bacula-dir: Symbol `uar_create_temp1' has different size in 
> shared object, consider re-linking
> /opt/bacula/bin/bacula-dir: Symbol `create_deltabs' has different size in 
> shared object, consider re-linking
> /opt/bacula/bin/bacula-dir: Symbol `uar_file' has different size in shared 
> object, consider re-linking
> /opt/bacula/bin/bacula-dir: Symbol `uar_create_temp' has different size in 
> shared object, consider re-linking
> /opt/bacula/bin/bacula-dir: Symbol `uar_jobid_fileindex_from_dir' has 
> different size in shared object, consider re-linking
> 
> The solution is very simple in my case, just delete everything from lib 
> (single file Bacula install) and redo make install, and all works, but on a 
> standard system where .so files are installed in /usr/lib, it is much more 
> complicated.
> 
I'm wondering that this is not exactly the same as what has been
happening all the time. The change from 1.0.0 to 5.0.0 only changes the
major number of the libs. This means that we now can have both a version
4 bacula enterprise edition and a opensource major version 5 client
without things interfering. I changed the 5.1.x code to create 5.1.0
shared libs but thing remains that you need to update the libs when you
compile a new version of bacula (for version 5.0.x and 5.1.x you
end up with major version 5 libs which for sure are not compatible).
The only way to fix that is walk very fast through the major numbers as
on every change to a c++ function the function names changes due to c++
doing name mangling (the nice things is even on Solaris a library
created by the SUN compiler cannot be used by a gcc compiled program
as gcc uses a different name mangling then SUN CC). So I guess we have
to learn to live with it or have some sort of auto increment but you
also don't get to happy when you look into your bacula lib dir and see

libbac.so.5
libbac.so.6
..
libbac.so.1024

etc.

> Do you have any idea what went wrong and how to correct it?
> 
See above, its probably something that we cannot really fix easily, but
thinking about I also see you mention that a certain bat version also
only works with a certain dir version we also don't do protocol
versioning there (Not say that is bad but just something we may need
to live with.) The only other things I could think about is using
symbol numbering something I see SUN uses in there normal C library
but I wonder if that is very portable. This means we need to have a
look at making a mapfile and I wonder if that is something that can
work for a C++ library. Maybe someone else can investigate it as I
am currently a bit to busy I might have a search on google myself.

Marco

Re: [Bacula-devel] Problem installing Bacula

[Kern S. <ke...@si...>]

Hello Marco,

I think you have completely misunderstood the point of my email and the 
problem I posed.  

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.

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.

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.

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?

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?

Best regards,

Kern

On Tuesday 09 February 2010 19:59:15 Marco van Wieringen wrote:
> On Tue, 2010-02-09 at 14:18 +0100, Kern Sibbald wrote:
> > Hello Marco,
> >
> > Unfortunately, something is not working totally correctly with Bacula
> > installation with shared libraries.  I ran into a problem where
> > everything was failing after your patch to update to use .so.5 instead of
> > .so.1
>
> Ok that doesn't sound to good.
>
> > What I ended up in my lib installation directory was stuff like:
> >
> > libbacsql.la
> > lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so ->
> > libbacsql.so.5.0.0
> > lrwxrwxrwx 1 kern kern      18 2010-02-09 14:00 libbacsql.so.5 ->
> > libbacsql.so.5.0.0
> > -rwxr-xr-- 1 kern kern  420362 2010-02-09 14:00 libbacsql.so.5.0.0
> >
> > Plus:
> >
> > libbacsql.so.1.0.0
>
> Ok that could be because I forgot to change the cats version to 5.0.0
> and only changed the other 4 libs in the first patch.
>
> > which was left over from a prior install.  Now, one would normally think
> > that everything would work correctly.  Here is a listing of what
> > bacula-dir wanted:
> >
> > ldd bacula-dir
> >         linux-gate.so.1 =>  (0xb7f1f000)
> >         libbacfind.so.5 => /opt/bacula/lib/libbacfind.so.5 (0xb7f10000)
> >         libbacsql.so.5 => /opt/bacula/lib/libbacsql.so.5 (0xb7eed000)
> >         libbacpy.so.5 => /opt/bacula/lib/libbacpy.so.5 (0xb7eea000)
> >         libbaccfg.so.5 => /opt/bacula/lib/libbaccfg.so.5 (0xb7ee3000)
> >         libbac.so.5 => /opt/bacula/lib/libbac.so.5 (0xb7e92000)
> >         libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15
> > (0xb7c99000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1
> > (0xb7c67000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7c4e000)
> > libz.so.1 => /usr/lib/libz.so.1 (0xb7c39000)
> >         libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0
> > (0xb7c21000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c1d000)
> > libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7bdb000)
> > libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7a99000)
> >         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb79a5000)
> >         libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7980000)
> >         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7975000)
> >         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7826000)
> >         /lib/ld-linux.so.2 (0xb7f20000)
> >
> > all that looks perfectly fine.  In principle, the extra
> > libbacsql.so.1.0.0, should not harm anything, but when I execute
> > bacula-dir, I get:
>
> Ok it has linked in all .so.5 versions so that looks ok.
>
> > Starting the Bacula Director daemon
> > /opt/bacula/bin/bacula-dir: Symbol `uar_create_temp1' has different size
> > in shared object, consider re-linking
> > /opt/bacula/bin/bacula-dir: Symbol `create_deltabs' has different size in
> > shared object, consider re-linking
> > /opt/bacula/bin/bacula-dir: Symbol `uar_file' has different size in
> > shared object, consider re-linking
> > /opt/bacula/bin/bacula-dir: Symbol `uar_create_temp' has different size
> > in shared object, consider re-linking
> > /opt/bacula/bin/bacula-dir: Symbol `uar_jobid_fileindex_from_dir' has
> > different size in shared object, consider re-linking
> >
> > The solution is very simple in my case, just delete everything from lib
> > (single file Bacula install) and redo make install, and all works, but on
> > a standard system where .so files are installed in /usr/lib, it is much
> > more complicated.
>
> I'm wondering that this is not exactly the same as what has been
> happening all the time. The change from 1.0.0 to 5.0.0 only changes the
> major number of the libs. This means that we now can have both a version
> 4 bacula enterprise edition and a opensource major version 5 client
> without things interfering. I changed the 5.1.x code to create 5.1.0
> shared libs but thing remains that you need to update the libs when you
> compile a new version of bacula (for version 5.0.x and 5.1.x you
> end up with major version 5 libs which for sure are not compatible).
> The only way to fix that is walk very fast through the major numbers as
> on every change to a c++ function the function names changes due to c++
> doing name mangling (the nice things is even on Solaris a library
> created by the SUN compiler cannot be used by a gcc compiled program
> as gcc uses a different name mangling then SUN CC). So I guess we have
> to learn to live with it or have some sort of auto increment but you
> also don't get to happy when you look into your bacula lib dir and see
>
> libbac.so.5
> libbac.so.6
> ..
> libbac.so.1024
>
> etc.
>
> > Do you have any idea what went wrong and how to correct it?
>
> See above, its probably something that we cannot really fix easily, but
> thinking about I also see you mention that a certain bat version also
> only works with a certain dir version we also don't do protocol
> versioning there (Not say that is bad but just something we may need
> to live with.) The only other things I could think about is using
> symbol numbering something I see SUN uses in there normal C library
> but I wonder if that is very portable. This means we need to have a
> look at making a mapfile and I wonder if that is something that can
> work for a C++ library. Maybe someone else can investigate it as I
> am currently a bit to busy I might have a search on google myself.

>
> Marco

Re: [Bacula-devel] Problem installing Bacula

[Marco v. W. <mv...@pl...>]

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.

> 
> 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.
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.

Marco

Re: [Bacula-devel] Problem installing Bacula

[Marco v. W. <mv...@pl...>]

On Wed, Feb 10, 2010 at 09:48:38AM +0100, 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.
> 
> > 
> > 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.

To answer my own question:

I now have this:

9:58 [root:corona][62] /opt/ELMbacula/lib > ls -l                                                                                                                                                                                
total 4246
drwxr-xr-x   2 bin      bin           32 Feb 10 09:54 amd64
-r-xr-xr-x   1 bin      bin          908 Feb 10 09:54 libbac.la
lrwxrwxrwx   1 root     root          11 Feb 10 09:54 libbac.so -> libbac.so.5
lrwxrwxrwx   1 bin      bin           15 Feb 10 09:53 libbac.so.1 -> libbac.so.1.0.0
-r-xr-xr-x   1 bin      bin       647888 Oct 27 21:27 libbac.so.1.0.0
lrwxrwxrwx   1 root     root          15 Feb  7 15:54 libbac.so.5 -> libbac.so.5.0.0
-r-xr-xr-x   1 bin      bin       649808 Feb  7 14:19 libbac.so.5.0.0
-r-xr-xr-x   1 bin      bin          926 Feb 10 09:54 libbaccfg.la
lrwxrwxrwx   1 root     root          14 Feb 10 09:54 libbaccfg.so -> libbaccfg.so.5
lrwxrwxrwx   1 bin      bin           18 Feb 10 09:53 libbaccfg.so.1 -> libbaccfg.so.1.0.0
-r-xr-xr-x   1 bin      bin        44384 Oct 27 21:27 libbaccfg.so.1.0.0
lrwxrwxrwx   1 root     root          18 Feb  7 15:54 libbaccfg.so.5 -> libbaccfg.so.5.0.0
-r-xr-xr-x   1 bin      bin        42048 Feb  7 14:19 libbaccfg.so.5.0.0
-r-xr-xr-x   1 bin      bin          932 Feb 10 09:54 libbacfind.la
lrwxrwxrwx   1 root     root          15 Feb 10 09:54 libbacfind.so -> libbacfind.so.5
lrwxrwxrwx   1 bin      bin           19 Feb 10 09:53 libbacfind.so.1 -> libbacfind.so.1.0.0
-r-xr-xr-x   1 bin      bin        90964 Oct 27 21:27 libbacfind.so.1.0.0
lrwxrwxrwx   1 root     root          19 Feb  7 15:54 libbacfind.so.5 -> libbacfind.so.5.0.0
-r-xr-xr-x   1 bin      bin        86344 Feb  7 14:19 libbacfind.so.5.0.0
-r-xr-xr-x   1 bin      bin          956 Feb 10 09:54 libbacpy.la
lrwxrwxrwx   1 root     root          13 Feb 10 09:54 libbacpy.so -> libbacpy.so.5
lrwxrwxrwx   1 bin      bin           17 Feb 10 09:53 libbacpy.so.1 -> libbacpy.so.1.0.0
-r-xr-xr-x   1 bin      bin        21348 Oct 27 21:27 libbacpy.so.1.0.0
lrwxrwxrwx   1 root     root          17 Feb  7 15:54 libbacpy.so.5 -> libbacpy.so.5.0.0
-r-xr-xr-x   1 bin      bin        20724 Feb  7 14:19 libbacpy.so.5.0.0
-r-xr-xr-x   1 bin      bin          955 Feb 10 09:54 libbacsql.la
lrwxrwxrwx   1 root     root          14 Feb 10 09:54 libbacsql.so -> libbacsql.so.5
lrwxrwxrwx   1 bin      bin           18 Feb 10 09:53 libbacsql.so.1 -> libbacsql.so.1.0.0
-r-xr-xr-x   1 bin      bin       214936 Oct 27 21:27 libbacsql.so.1.0.0
lrwxrwxrwx   1 root     root          18 Feb  7 15:54 libbacsql.so.5 -> libbacsql.so.5.0.0
-r-xr-xr-x   1 bin      bin       227152 Feb  7 14:19 libbacsql.so.5.0.0
drwxr-xr-x   3 bin      bin            4 Feb  7 15:54 plugins
9:58 [root:corona][63] /opt/ELMbacula/lib > cd amd64 
9:58 [root:corona][64] /opt/ELMbacula/lib/amd64 > ls -l                                                                                                                                                                          
total 4858
-r-xr-xr-x   1 bin      bin          966 Feb 10 09:54 libbac.la
lrwxrwxrwx   1 root     root          11 Feb 10 09:54 libbac.so -> libbac.so.5
lrwxrwxrwx   1 bin      bin           15 Feb 10 09:53 libbac.so.1 -> libbac.so.1.0.0
-r-xr-xr-x   1 bin      bin       722104 Oct 27 21:27 libbac.so.1.0.0
lrwxrwxrwx   1 root     root          15 Feb  7 15:54 libbac.so.5 -> libbac.so.5.0.0
-r-xr-xr-x   1 bin      bin       720080 Feb  7 14:01 libbac.so.5.0.0
-r-xr-xr-x   1 bin      bin          984 Feb 10 09:54 libbaccfg.la
lrwxrwxrwx   1 root     root          14 Feb 10 09:54 libbaccfg.so -> libbaccfg.so.5
lrwxrwxrwx   1 bin      bin           18 Feb 10 09:53 libbaccfg.so.1 -> libbaccfg.so.1.0.0
-r-xr-xr-x   1 bin      bin        54136 Oct 27 21:27 libbaccfg.so.1.0.0
lrwxrwxrwx   1 root     root          18 Feb  7 15:54 libbaccfg.so.5 -> libbaccfg.so.5.0.0
-r-xr-xr-x   1 bin      bin        51152 Feb  7 14:01 libbaccfg.so.5.0.0
-r-xr-xr-x   1 bin      bin          990 Feb 10 09:54 libbacfind.la
lrwxrwxrwx   1 root     root          15 Feb 10 09:54 libbacfind.so -> libbacfind.so.5
lrwxrwxrwx   1 bin      bin           19 Feb 10 09:53 libbacfind.so.1 -> libbacfind.so.1.0.0
-r-xr-xr-x   1 bin      bin       104696 Oct 27 21:27 libbacfind.so.1.0.0
lrwxrwxrwx   1 root     root          19 Feb  7 15:54 libbacfind.so.5 -> libbacfind.so.5.0.0
-r-xr-xr-x   1 bin      bin        97928 Feb  7 14:01 libbacfind.so.5.0.0
-r-xr-xr-x   1 bin      bin         1014 Feb 10 09:54 libbacpy.la
lrwxrwxrwx   1 root     root          13 Feb 10 09:54 libbacpy.so -> libbacpy.so.5
lrwxrwxrwx   1 bin      bin           17 Feb 10 09:53 libbacpy.so.1 -> libbacpy.so.1.0.0
-r-xr-xr-x   1 bin      bin        26584 Oct 27 21:27 libbacpy.so.1.0.0
lrwxrwxrwx   1 root     root          17 Feb  7 15:54 libbacpy.so.5 -> libbacpy.so.5.0.0
-r-xr-xr-x   1 bin      bin        25712 Feb  7 14:01 libbacpy.so.5.0.0
-r-xr-xr-x   1 bin      bin         1013 Feb 10 09:54 libbacsql.la
lrwxrwxrwx   1 root     root          14 Feb 10 09:54 libbacsql.so -> libbacsql.so.5
lrwxrwxrwx   1 bin      bin           18 Feb 10 09:53 libbacsql.so.1 -> libbacsql.so.1.0.0
-r-xr-xr-x   1 bin      bin       238232 Oct 27 21:27 libbacsql.so.1.0.0
lrwxrwxrwx   1 root     root          18 Feb  7 15:54 libbacsql.so.5 -> libbacsql.so.5.0.0
-r-xr-xr-x   1 bin      bin       250920 Feb  7 14:01 libbacsql.so.5.0.0


e.g. I have both the old and the new libs in one place.

and when I then try

/opt/ELMbacula/sbin/bacula-fd: illegal option -- x
Copyright (C) 2000-2010 Free Software Foundation Europe e.V.

Version: 5.0.1 (06 February 2010)

Usage: bacula-fd [-f -s] [-c config_file] [-d debug_level]
        -c <file>   use <file> as configuration file
        -d <nn>     set debug level to <nn>
        -dt         print a timestamp in debug output
        -f          run in foreground (for debugging)
        -g          groupid
        -k          keep readall capabilities
        -m          print kaboom output (for debugging)
        -s          no signals (for debugging)
        -t          test configuration file and exit
        -u          userid
        -v          verbose user messages
        -?          print this message.

9:59 [root:corona][66] /opt/ELMbacula/lib/amd64 > /opt/ELMbacula/sbin/bacula-sd -x                                                                                                                                               
/opt/ELMbacula/sbin/bacula-sd: illegal option -- x
Copyright (C) 2000-2010 Free Software Foundation Europe e.V.

Version: 5.0.1 (06 February 2010)

Usage: stored [options] [-c config_file] [config_file]
        -c <file>   use <file> as configuration file
        -d <nn>     set debug level to <nn>
        -dt         print timestamp in debug output
        -f          run in foreground (for debugging)
        -g <group>  set groupid to group
        -m          print kaboom output (for debugging)
        -p          proceed despite I/O errors
        -s          no signals (for debugging)
        -t          test - read config and exit
        -u <user>   userid to <user>
        -v          verbose user messages
        -?          print this message.

9:59 [root:corona][67] /opt/ELMbacula/lib/amd64 > /opt/ELMbacula/sbin/bacula-dir -x                                                                                                                                              
/opt/ELMbacula/sbin/bacula-dir: illegal option -- x
Copyright (C) 2000-2010 Free Software Foundation Europe e.V.

Version: 5.0.1 (06 February 2010)

Usage: dird [-f -s] [-c config_file] [-d debug_level] [config_file]
       -c <file>   set configuration file to file
       -d <nn>     set debug level to <nn>
       -dt         print timestamp in debug output
       -f          run in foreground (for debugging)
       -g          groupid
       -m          print kaboom output (for debugging)
       -r <job>    run <job> now
       -s          no signals
       -t          test - read configuration and exit
       -u          userid
       -v          verbose user messages
       -?          print this message.

It just seems to work (Ok I know this is on Solaris but dynamic loading should work the same on Linux)
So the only thing I can think of is that there were old 5.0.0 libs with older symbols which lead
to the error you are seeing. I would like to see what happens on Linux when you do exactly the same
e.g. put the 1.0.0 libs back.

Marco

Re: [Bacula-devel] Problem installing Bacula

[Kern S. <ke...@si...>]

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

Re: [Bacula-devel] Problem installing Bacula

[Marco v. W. <mv...@pl...>]

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

Re: [Bacula-devel] Problem installing Bacula

[Martin S. <ma...@li...>]

>>>>> 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?

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.

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).


> 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.

__Martin

Re: [Bacula-devel] Problem installing Bacula

[Marco v. W. <mv...@pl...>]

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

Re: [Bacula-devel] Problem installing Bacula

[Kern S. <ke...@si...>]

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.

> Do they export an API that non-Bacula programs can use?

We have not explicitly documented the interfaces to the libraries, but some 
users are amazingly enough using our shared libraries.  I suspect that over 
time we will fix many of the interfaces (calling sequences) and publish them.

>
> 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.

>
> 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.

>
> > 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.

We have switched from using libtool -version-tool to using -release, which 
means if the current code works as we expect, we will release version 5.0.1 
with libraries either versioned as 5.0.0 or 5.0.1

Regards,

Kern

Re: [Bacula-devel] Problem installing Bacula

[Martin S. <ma...@li...>]

>>>>> 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 :-)


> > 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.


> > 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.

How about reordering the options?  I.e. change

$(LIBTOOL_LINK) $(CXX) $(WLDFLAGS) $(LDFLAGS) -L../lib -L../findlib -o $@ ...

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.

__Martin

Re: [Bacula-devel] Problem installing Bacula

[Kern S. <ke...@si...>]

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

Re: [Bacula-devel] Problem installing Bacula

[Martin S. <ma...@li...>]

>>>>> On Wed, 10 Feb 2010 19:50:10 +0100, Marco van Wieringen said:
> 
> On Wed, 2010-02-10 at 18:23 +0000, Martin Simmons wrote:
> 
> > 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).

Yes, but libtool already takes care of this -- if it didn't, then the
/opt/bacula approach wouldn't work.  Certainly on Linux and FreeBSD, the
binaries end up containing an RPATH element in the dynamic section.

__Martin

Re: [Bacula-devel] Problem installing Bacula

[Martin S. <ma...@li...>]

>>>>> 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