[
https://issues.apache.org/jira/browse/DAEMON-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278834#comment-13278834
]
Kevin Shaum commented on DAEMON-246:
------------------------------------
I ran afoul of this too, and I'm dropping back to jsvc 1.0.9 for now as a
result.
I'd suggest one minor change to the patch: check for libcap.so first, before
the version-specific names. If a sysadmin has set up libcap.so as a symlink to
indicate which version is preferred, jsvc should respect that preference.
> 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
> Attachments: patch.txt
>
>
> 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
