[prev in list] [next in list] [prev in thread] [next in thread]
List: bacula-bugs
Subject: [Bacula-bugs] [bacula 0001803]: libbaccats-5.2.3.so symbolic link not found because 'ldconfig' does
From: Mantis Bug Tracker <nobody () bugs ! bacula ! org>
Date: 2012-01-25 16:53:55
Message-ID: 0dce21492ccb6085d8e67b9c41996e73 () bugs ! bacula ! org
[Download RAW message or body]
The following issue has been CLOSED
======================================================================
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: closed
Resolution: no change required
Fixed in Version:
======================================================================
Date Submitted: 2011-12-26 00:11 UTC
Last Modified: 2012-01-25 16:53 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.
----------------------------------------------------------------------
(0006126) marcovw (developer) - 2011-12-31 20:29
http://bugs.bacula.org/view.php?id=1803#c6126
----------------------------------------------------------------------
Regarding the last comments. 4.1.25 is NOT an old version
its the enterprise version which eventually will become
Bacula Enterprise 6.0.0 so it even newer code then 5.2.3
so don't be fooled by those version numbers.
Regarding the second point what you see is the
proper use of rpath by ld.so so there is nothing
special there.
I did some googling around and found the cause of your
problems which are as we expected a self inflicted wound.
----------------------------------------------------------------------
(0006127) marcovw (developer) - 2011-12-31 20:42
http://bugs.bacula.org/view.php?id=1803#c6127
----------------------------------------------------------------------
You are making a so called self inflicted wound.
On Linux they think they know everything better
then on any platform in the world. Which gets
kind of frustrating. They borrow or copy things
from other well working platforms (Solaris, *BSD
etc) and then break it or give it a stupid twist.
The whole rpath stuff even got its own wiki
on debian:
http://wiki.debian.org/RpathIssue
The text there is completely ridiculous and I
completely do not agree that rpath is a wrong
thing to use (the whole ld.so cache is so bad
but its the Linux way of doing things.) Maybe
they can take a look at a good implementation
like the crle dynamic linking on Solaris. ELF
has a very nice RPATH implementation and I think
libtool should be using it but it has some very
stupid defaults for Linux which seem to be
introduced by people who adhere the stupid idea
that rpath is wrong.
As it seems libtool on Linux will remove any
rpath entry when the library is in a path
that is in the ld.conf.conf.
So when you put additional entries into ld.so.conf
you effectively are removing RPATH entries from
your binaries.
There are a couple of workarounds:
- remove the additional paths from ld.so.conf
and use proper rpaths in your binaries.
- patch libtool back to normal behaviour
(ain't gonna happen upstream and we don't want
to support a private copy which cannot
be upgraded. But you could hack around
yourself) But libtool is kind of bad to read.
- use chrpath to change the rpath
something like: chrpath -r <lib> <binary>
See
http://fwarmerdam.blogspot.com/2010/12/rpath-runpath-and-ldlibrarypath.html
and
http://linux.die.net/man/1/chrpath
Then again it probably won't work as again Linux has a bad
implementation and on Solaris you can change the rpath because
there is room in the ELF header to address the problem but not
on Linux (what a surprise ...)
- Hard link the catalog library to the generic name.
- Copy the catalog library to the generic name.
- Set an LD_LIBRARY_PATH which overrides ld.so.cache etc.
Thats the last I'm going to say on the matter. But Kern
may have something to say.
----------------------------------------------------------------------
(0006128) starlight (reporter) - 2011-12-31 20:45
http://bugs.bacula.org/view.php?id=1803#c6128
----------------------------------------------------------------------
Well 4.1.25 and 5.2.3 are not the same, regardless
of their relative age. Not a valid comparison in
the realm of software development.
> I did some googling around and found the cause of your
> problems which are as we expected a self inflicted wound.
That's rather vague. Precisely what are you
referring to? A link would suffice.
You did not address (2) above. Are you using
a custom compiled 'glibc' environment rather
than the RHEL or CentOS distribution 'glibc'?
----------------------------------------------------------------------
(0006129) starlight (reporter) - 2011-12-31 20:49
http://bugs.bacula.org/view.php?id=1803#c6129
----------------------------------------------------------------------
I see your material, postings crossed each other.
Based on your rant about how bad Linux is,
I'm assuming this is being closed with a
WONTFIX. Really that's all I was looking
for.
----------------------------------------------------------------------
(0006130) marcovw (developer) - 2011-12-31 22:58
http://bugs.bacula.org/view.php?id=1803#c6130
----------------------------------------------------------------------
You don't read what I'm saying there are multiple ways of
saving things you am getting by doing the thing you decided to do.
How I think about Linux is my own opinion and has nothing todo with
how Kern decides to close or not this bug.
Its just sad that some thing on Linux are so poorly implemented
and so some fixes just won't work. And at least I'm not going
to try to fix libtool which is putting this problems on you.
If you just have a proper RPATH things would just work.
Again I tried to give some input on why thing are happening to
you. There are solutions but we are not going to push a solution
that will break other build types. So either install in a normal
directory or use the one build dir bacula mantra of /opt/bacula
and don't add things to /etc/ld.so.conf and you should be fine.
Making your own layout is fine you just have to face the things
it implies.
----------------------------------------------------------------------
(0006131) starlight (reporter) - 2011-12-31 23:16
http://bugs.bacula.org/view.php?id=1803#c6131
----------------------------------------------------------------------
You have missed the point here. This is
glitch that is a nuisance and all I have
been trying to do is have the problem fixed
for the longer-term. As is said above,
it's trivial to work around.
If you hadn't spent so much time trying
to blow me off claiming that my typical
RHEL/CentOS 6.2 configuration is usual
in comparison to the non-standard cross-
compile environment at your end, you would
have realized that the problem is fixed in
the 4.1.25 (future) version as it's clear
that someone added a -Wl,-rpath=... to
the build scripts in that release.
As far as Linux being different that what
you're familiar with--get used to it.
Solaris has been relegated to a minuscule
corner of the market and will never return
to prominence.
----------------------------------------------------------------------
(0006133) marcovw (developer) - 2012-01-01 10:01
http://bugs.bacula.org/view.php?id=1803#c6133
----------------------------------------------------------------------
A tip for the future start being less of a prick and
maybe people will take you seriously.
Maybe also start reading thing people say as maybe
then you would have seen that someone else was
trying to give you an explanation as to why you run into
the problems you run into.
And it seems obvious you don't understand what
you are talking about as 4.1.25 is using the same
linking code as you only because the directory Kern
is using is not a default dir or in ld.so.conf makes
him get a proper rpath (e.g. adding libtool the
proper ld flags).
But thanks for reminding me why opensource development
is such a nuance these last years.
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
2011-12-31 20:29 marcovw Note Added: 0006126
2011-12-31 20:42 marcovw Note Added: 0006127
2011-12-31 20:45 starlight Note Added: 0006128
2011-12-31 20:49 starlight Note Added: 0006129
2011-12-31 22:58 marcovw Note Added: 0006130
2011-12-31 23:16 starlight Note Added: 0006131
2012-01-01 10:01 marcovw Note Added: 0006133
2012-01-25 16:53 kern Status assigned => closed
2012-01-25 16:53 kern Resolution reopened => no change
required
======================================================================
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Bacula-bugs mailing list
Bacula-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-bugs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic