commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk (JIRA)" <>
Subject [jira] [Resolved] (DAEMON-246) jsvc fails to load from /lib64
Date Mon, 22 Oct 2012 06:46:13 GMT


Mladen Turk resolved DAEMON-246.

       Resolution: Fixed
    Fix Version/s: 1.0.11

Patch applied.
> jsvc fails to load from /lib64
> ------------------------------------------
>                 Key: DAEMON-246
>                 URL:
>             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
>             Fix For: 1.0.11
>         Attachments: patch.txt
> I see this when running jsvc -debug ...
> Attemtping to load library /lib/
> Attemtping to load library /lib/
> Attemtping to load library /lib/
> Attemtping to load library /usr/lib/
> Attemtping to load library /usr/lib/
> Attemtping to load library /usr/lib/
> failed loading capabilities library -- /usr/lib/ 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 is found at /lib32/
> These alternative library locations are mentioned in the Linux filesystem hierarchy standard
> 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 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 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
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
For more information on JIRA, see:

View raw message