Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 22 Oct 2012 06:46:13 +0000 (UTC)
From: "Mladen Turk (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <1045145140.8698.1350888373669.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1704628105.34549.1331135819342.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (DAEMON-246) jsvc fails to load libcap.so.2 from
 /lib64
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DAEMON-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mladen Turk resolved DAEMON-246.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 1.0.11

Patch applied.
Thanks!
                
> 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
>             Fix For: 1.0.11
>
>         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
For more information on JIRA, see: http://www.atlassian.com/software/jira