Menu
▾
▴
[Bacula-bugs] [bacula 0001803]: libbaccats-5.2.3.so symbolic link not found because 'ldconfig' does not include it
|
From: Mantis B. T. <no...@bu...> - 2011-12-31 19:32:57
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=1803 ====================================================================== Reported By: starlight Assigned To: kern ====================================================================== Project: bacula Issue ID: 1803 Category: start/stop scripts Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2011-12-26 00:11 UTC Last Modified: 2011-12-31 19:32 UTC ====================================================================== Summary: libbaccats-5.2.3.so symbolic link not found because 'ldconfig' does not include it Description: When starting any daemon or utility, receive the message error while loading shared libraries: libbaccats-5.2.3.so: cannot open shared object file: No such file or directory This seems to be because 'ldconfig' does not include the symbolic link with the above name since it points to the rather different libbaccats-mysql-5.2.3.so running ldconfig ldconfig -p | fgrep libbaccats shows only libbaccats-mysql-5.2.3.so (libc6,x86-64) => /usr/local/lib64/libbaccats-mysql-5.2.3.so Additional Information: Worked around this issue by adding LD_LIBRARY_PATH=/usr/local/lib64 export LD_LIBRARY_PATH to several scripts. ====================================================================== ---------------------------------------------------------------------- (0006103) kern (administrator) - 2011-12-29 07:42 http://bugs.bacula.org/view.php?id=1803#c6103 ---------------------------------------------------------------------- I am assuming you are referring to 5.2.3 rather than 5.0.3, so have changed it. If you are referring to 5.0.3, we request you upgrade to 5.2.3. It appears you have build Bacula incorrectly, or more likely you have incorrectly installed it, or possibly you obtained binaries that were not properly constructed. We had some problems such as you describe with 5.2.2 or older when one attempted to build multiple times, but to the best of our knowledge they are all corrected in version 5.2.3. Since you have provided no information on where your binaries came from or how you built them, there is nothing we can do. The workaround you suggest certainly can work, but it is not necessary if Bacula is properly installed. Since you have a workaround, there is not much use in continuing the bug report. ---------------------------------------------------------------------- (0006105) starlight (reporter) - 2011-12-29 17:08 http://bugs.bacula.org/view.php?id=1803#c6105 ---------------------------------------------------------------------- Built it correctly. Problem is simple: The start-up scripts require LD_LIBRARY_PATH to be set when the libraries are not installed in any of the trusted system library directories. Those are /ilb /lib64 /usr/lib /usr/lib64 These are hard-coded in 'ld.so.conf' and cannot be changed. Even if /usr/local/lib64 is added to a file in /etc/ld.so.conf.d and 'ldconfig' is run, the system will not automatically search /usr/local/lib64. Only libraries that are listed in the 'ldconfig' cache (as seen with 'ldconfig -p') will be considered. Since Bacula uses a symbolic link to resolve which if the DBM libraries are used, that symlink will not be seen unless LD_LIBRARY_PATH is set. Alternately the code could load the DBM library dynamically based on something in the configuration. ---------------------------------------------------------------------- (0006107) starlight (reporter) - 2011-12-29 20:45 http://bugs.bacula.org/view.php?id=1803#c6107 ---------------------------------------------------------------------- Meant to say "hard coded in 'ld.so' and cannot be changed." ---------------------------------------------------------------------- (0006108) kern (administrator) - 2011-12-30 06:09 http://bugs.bacula.org/view.php?id=1803#c6108 ---------------------------------------------------------------------- I believe that you have an unusual or broken system or are not building and installing Bacula correctly this is based on the fact that thousands of users have installed Bacula without this problem, and in my own case, see below: My LD_PATH_LIBRARY is not set, and I am able to install Bacula in multiple places on my systems (at least 3) (including on RHEL 6), though I never tried /usr/local/lib64 since that would pollute installed system program's space as well as making backing up Bacula much more difficult. Since you have a work around, there is nothing to do. ---------------------------------------------------------------------- (0006109) starlight (reporter) - 2011-12-30 15:20 http://bugs.bacula.org/view.php?id=1803#c6109 ---------------------------------------------------------------------- You can certainly skip fixing this if you prefer as it's easy to work around. But be aware that this is how RedHat and Novell enterprise distributions handle library paths. Obviously you have never tried installing the libraries in a directory other than the four hard-coded "trusted" ones. It is customary to install locally compiled software in the /usr/local tree rather than in /usr. Bacula is unusual in that the install defaults to /usr. ---------------------------------------------------------------------- (0006110) starlight (reporter) - 2011-12-30 17:37 http://bugs.bacula.org/view.php?id=1803#c6110 ---------------------------------------------------------------------- Since there seems to be an issue of belief here, I ran it with LD_DEBUG=all set and uploaded the output as attachments above. Crystal clear that the default library search path does not include /usr/local/lib64. One can also solve this problem by adding an RPATH to the executable via the -Wl,-rpath=... gcc options when linking. If you can find some way to change the default library search path other than modifying the source code for /lib64/ld-2.12.so in the 'glibc' package, I'd be interesting in learning about it. Under Solaris the 'crle' tool will do this, but AFIK no Linux equivalent exists. ---------------------------------------------------------------------- (0006111) starlight (reporter) - 2011-12-30 18:01 http://bugs.bacula.org/view.php?id=1803#c6111 ---------------------------------------------------------------------- Forgot to state the obvious: ldfail.txt was run with LD_LIBRARY_PATH not set ldsuccess.txt was run with LD_LIBRARY_PATH=/usr/local/lib64 ---------------------------------------------------------------------- (0006112) kern (administrator) - 2011-12-31 07:50 http://bugs.bacula.org/view.php?id=1803#c6112 ---------------------------------------------------------------------- I'll stick by my comments in 06108. It is also possible that you are moving or copying the Bacula binaries to another location after installation, which is not supported by Bacula. You are going in a direction that Bacula does not support in insisting that Bacula needs LD_LIBRARY_PATH. Bacula doesn't need it since during installation, the paths to its own shared objects are "hard coded" by using RPATH. Typical loader output when Bacula is built and installed correctly: 3580: file=libbacfind-4.1.25.so [0]; needed by ./bacula-dir [0] 3580: find library=libbacfind-4.1.25.so [0]; searching 3580: search path=/home/kern/bacula/k/regress/bin/tls/x86_64:/home/kern/bacula/k/regress/bin/tls:/home/kern/bacula/k/regress/bin/x86_64:/home/kern/bacula/k/reg 3580: trying file=/home/kern/bacula/k/regress/bin/tls/x86_64/libbacfind-4.1.25.so 3580: trying file=/home/kern/bacula/k/regress/bin/tls/libbacfind-4.1.25.so 3580: trying file=/home/kern/bacula/k/regress/bin/x86_64/libbacfind-4.1.25.so 3580: trying file=/home/kern/bacula/k/regress/bin/libbacfind-4.1.25.so 3580: 3580: file=libbacfind-4.1.25.so [0]; generating link map 3580: dynamic: 0x00007feb2c4e0e00 base: 0x00007feb2c2d4000 size: 0x000000000020d3b8 3580: entry: 0x00007feb2c2d7200 phdr: 0x00007feb2c2d4040 phnum: 7 3580: 3580: 3580: file=libbacsql-4.1.25.so [0]; needed by ./bacula-dir [0] 3580: find library=libbacsql-4.1.25.so [0]; searching 3580: search path=/home/kern/bacula/k/regress/bin (RPATH from file ./bacula-dir) 3580: trying file=/home/kern/bacula/k/regress/bin/libbacsql-4.1.25.so 3580: 3580: file=libbacsql-4.1.25.so [0]; generating link map 3580: dynamic: 0x00007feb2c2d2d00 base: 0x00007feb2c0ad000 size: 0x00000000002268c8 3580: entry: 0x00007feb2c0b3d90 phdr: 0x00007feb2c0ad040 phnum: 7 3580: 3580: 3580: file=libbaccats-4.1.25.so [0]; needed by ./bacula-dir [0] 3580: find library=libbaccats-4.1.25.so [0]; searching 3580: search path=/home/kern/bacula/k/regress/bin (RPATH from file ./bacula-dir) 3580: trying file=/home/kern/bacula/k/regress/bin/libbaccats-4.1.25.so 3580: 3580: file=libbaccats-4.1.25.so [0]; generating link map 3580: dynamic: 0x00007feb2c0abdf8 base: 0x00007feb2bea6000 size: 0x0000000000206248 3580: entry: 0x00007feb2bea8800 phdr: 0x00007feb2bea6040 phnum: 7 3580: 3580: 3580: file=libbacpy-4.1.25.so [0]; needed by ./bacula-dir [0] 3580: find library=libbacpy-4.1.25.so [0]; searching 3580: search path=/home/kern/bacula/k/regress/bin (RPATH from file ./bacula-dir) Please do not re-open this bug report. ---------------------------------------------------------------------- (0006116) starlight (reporter) - 2011-12-31 08:17 http://bugs.bacula.org/view.php?id=1803#c6116 ---------------------------------------------------------------------- Well then the bug is that the RPATH is not being added to 'bacula-dir' as it should be under CentOS 6. You keep accusing me of "moving" things, but I assure you that I have not --all the files are exactly where "make install" placed them. Under the CentOS 6.2, 5.7 and 4.9 builds: $ readelf -a bacula-dir | fgrep RPATH $ readelf -a bacula-fd | fgrep RPATH # no output But for one of the libraries $ readelf -a libbaccats-mysql-5.2.3.so | fgrep RPATH 0x000000000000000f (RPATH) Library rpath: [/usr/lib64/mysql] Or perhaps 'libtool' assumes that if one is targeting /usr/local that the RPATH is not required, though clearly it is required. I'm uploading a bunch of the outputs from the build. ---------------------------------------------------------------------- (0006120) kern (administrator) - 2011-12-31 09:09 http://bugs.bacula.org/view.php?id=1803#c6120 ---------------------------------------------------------------------- Perhaps you should file a bug report with the autoconf guys. Please do not re-open this bug. ---------------------------------------------------------------------- (0006124) starlight (reporter) - 2011-12-31 16:45 http://bugs.bacula.org/view.php?id=1803#c6124 ---------------------------------------------------------------------- Ok, so for the record, you allow that this problem is real and refuse to fix it? If you agree I will not open it again. ---------------------------------------------------------------------- (0006125) starlight (reporter) - 2011-12-31 19:32 http://bugs.bacula.org/view.php?id=1803#c6125 ---------------------------------------------------------------------- Looked more carefully at your example and there are two notable concerns: 1) you are running an old version of Bacula (4.1.25), so the example is not valid. This issue is reported against 5.2.3. It's clear that the 4.2.25 build has an RPATH set with a -Wl,-rpath=... option in the link line for 'bacula-fd' and equally clear that this is not present in 5.2.3 when built on CentOS 4,5,6 and, by implication, RHEL 4,5,6. 2) the default system search path used by 'ld.so' has every path prefixed with "/home/kern/bacula/k/regress". This is quite interesting. How was it accomplished? It seems to imply a custom 'glibc' build, perhaps the result of a cross-compile environment setup. If so it does not represent a deployment target scenario, which is what this issue is about and is not a valid way to confirm or refute the issue. Issue History Date Modified Username Field Change ====================================================================== 2011-12-26 00:11 starlight New Issue 2011-12-29 07:42 kern Note Added: 0006103 2011-12-29 07:42 kern Status new => closed 2011-12-29 07:42 kern Resolution open => no change required 2011-12-29 07:42 kern Product Version 5.0.3 => 5.2.3 2011-12-29 17:08 starlight Note Added: 0006105 2011-12-29 17:08 starlight Status closed => feedback 2011-12-29 17:08 starlight Resolution no change required => reopened 2011-12-29 20:45 starlight Note Added: 0006107 2011-12-29 20:45 starlight Status feedback => new 2011-12-30 06:09 kern Note Added: 0006108 2011-12-30 06:09 kern Status new => closed 2011-12-30 06:09 kern Resolution reopened => no change required 2011-12-30 15:20 starlight Note Added: 0006109 2011-12-30 15:20 starlight Status closed => feedback 2011-12-30 15:20 starlight Resolution no change required => reopened 2011-12-30 17:30 starlight File Added: ldfail.txt 2011-12-30 17:30 starlight File Added: ldsuccess.txt 2011-12-30 17:37 starlight Note Added: 0006110 2011-12-30 17:37 starlight Status feedback => new 2011-12-30 18:01 starlight Note Added: 0006111 2011-12-31 07:50 kern Note Added: 0006112 2011-12-31 07:50 kern Assigned To => kern 2011-12-31 07:50 kern Status new => closed 2011-12-31 07:50 kern Resolution reopened => no change required 2011-12-31 08:17 starlight Note Added: 0006116 2011-12-31 08:17 starlight Status closed => feedback 2011-12-31 08:17 starlight Resolution no change required => reopened 2011-12-31 08:24 starlight File Added: bacula-5.2.3_buildfiles.tar.gz 2011-12-31 09:09 kern Note Added: 0006120 2011-12-31 09:09 kern Status feedback => closed 2011-12-31 09:09 kern Resolution reopened => won't fix 2011-12-31 16:45 starlight Note Added: 0006124 2011-12-31 16:45 starlight Status closed => feedback 2011-12-31 16:45 starlight Resolution won't fix => reopened 2011-12-31 19:32 starlight Note Added: 0006125 2011-12-31 19:32 starlight Status feedback => assigned ====================================================================== |