jsvc fails to load libcap.so.2 from /lib64
------------------------------------------

                 Key: DAEMON-246
                 URL: https://issues.apache.org/jira/browse/DAEMON-246
             Project: Commons Daemon
          Issue Type: Bug
          Components: Jsvc
    Affects Versions: 1.0.10
         Environment: Fedora Core 16 (x86_64, using an x86_64 jsvc), CentOS 5.5 
(x86_86, using an x86_64 jsvc), Debian Squeeze (x86_64, using an i686 jsvc), 
Debian Wheezy (x86_64, using an i686 jsvc)
            Reporter: Emily Middleton


I see this when running jsvc -debug ...

Attemtping to load library /lib/libcap.so.2
Attemtping to load library /lib/libcap.so.1
Attemtping to load library /lib/libcap.so
Attemtping to load library /usr/lib/libcap.so.2
Attemtping to load library /usr/lib/libcap.so.1
Attemtping to load library /usr/lib/libcap.so
failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared
object file: No such file or directory.

This does not work on 64bit Fedora, as the lib directory is /lib64/.

It also won't work if you're using a 32bit copy of jsvc on a 64bit copy of 
Debian, which has a similar problem (the 32bit copy of libcap.so.2 is found at 
/lib32/libcap.so.2).

These alternative library locations are mentioned in the Linux filesystem 
hierarchy standard 
(http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL).

The hard-coded /lib and /usr/lib paths in jsvc are counter-productive in the 
environments mentioned, and also in environments where the user expects to be 
able to control the library search path with the LD_LIBRARY_PATH environment 
variable.  jsvc should be utilising the normal ld.so search path.  This can be 
achieved even with a desire to be able to load either version 1 or 2 of libcap 
(as requested in https://issues.apache.org/jira/browse/DAEMON-234) because you 
don't need to give a full path to dlopen, according to its man page on Linux:

"If filename contains a slash ("/"), then it is interpreted as a (relative or 
absolute) pathname.  Otherwise, the dynamic linker searches for the library as 
follows ... (see ld.so(8) for further details)"

So the issue can be resolved by simply making libcap_locs contain the desired 
filenames rather than pathnames.  Patch will be attached shortly.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to