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