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