Hello,

On 07/23/2010 11:52 AM, Daniel Bareiro wrote:
> On Friday, 23 July 2010 02:13:51 +0200,
> Jeroen van Meeuwen wrote:
>
>> Hi there Daniel!
>
> Hi, Jeroen!
>
>>> But when trying to run the startup script, I get the following
>>> errors:
>>>
>>> [root@localhost scripts]# /etc/init.d/bacula start
>>> Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading 
>>> shared libraries:
>>> libbacpy-5.0.1.so: cannot open shared object file: No such file or directory
>>> Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading 
>>> shared libraries:
>>> libbacfind-5.0.1.so: cannot open shared object file: No such file or 
>>> directory
>>> Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while 
>>> loading shared libraries:
>>> libbacfind-5.0.1.so: cannot open shared object file: No such file or 
>>> directory
>>>
>>> But the files are:
>>>
>>> [root@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so
>>> -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so
>>>
>>> [root@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so
>>> -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so
>
>> Have you ran ldconfig? It generates the "available libraries" cache for the
>> dynamic linker, and the dynamic linker is relatively strict about not
>> searching various locations throughout the filesystem.
>>
>> You can verify dynamic linking capabilities with "ldd /path/to/binary".
>>
>> Also, you may want to consider Security Enhanced Linux. Verify with the
>> "sestatus" command whether SELinux is enforcing the targeted policy, and if
>> so, consider restoring the default context for the files freshly installed
>> using restorecon, and if all else fails, please get back to us with ls -Z
>> output ;-)
>
> I was also trying to install Bacula 5.0.1 using the same procedure as
> mentioned in previous email and I have the same problem. This procedure
> was successful in Debian with the difference that there I updated a
> previous version instead of installing from scratch.
>
> Like I said, I followed the steps mentioned in the other email (I did
> not run ldconfig manually) that had been successful in Debian. Using ldd
> with these two libraries, I get the following:
>
> [root@localhost init.d]# ldd /usr/lib/libbacpy-5.0.1.so
>          libstdc++.so.6 =>  /usr/lib64/libstdc++.so.6 (0x00002b4eb5ee7000)
>          libm.so.6 =>  /lib64/libm.so.6 (0x00002b4eb61e7000)
>          libc.so.6 =>  /lib64/libc.so.6 (0x00002b4eb646a000)
>          libgcc_s.so.1 =>  /lib64/libgcc_s.so.1 (0x00002b4eb67c2000)
>          /lib64/ld-linux-x86-64.so.2 (0x000000320a400000)
>
> [root@localhost init.d]# ldd /usr/lib/libbacfind-5.0.1.so
>          libstdc++.so.6 =>  /usr/lib64/libstdc++.so.6 (0x00002b97a2131000)
>          libm.so.6 =>  /lib64/libm.so.6 (0x00002b97a2431000)
>          libc.so.6 =>  /lib64/libc.so.6 (0x00002b97a26b4000)
>          libgcc_s.so.1 =>  /lib64/libgcc_s.so.1 (0x00002b97a2a0c000)
>          /lib64/ld-linux-x86-64.so.2 (0x000000320a400000)

what is the output of 'ldd /usr/sbin/bacula-sd' ?

>
> Comparing this output with the one I get with the same version of Bacula
> (5.0.1) installed with the same procedure in Debian, I'm seeing that in
> both files are additionally a reference to linux-vdso.so.1.
>
> Can this be the cause of the problem?
>
>
> Thanks for your reply.
>
> Regards,
> Daniel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users