Opened 15 years ago
Closed 15 years ago
#2859 closed defect (fixed)
libcap not found => Fixed in SVN
Reported by: | Ron Gage | Owned by: | |
---|---|---|---|
Component: | host support | Version: | VirtualBox 2.1.0 |
Keywords: | Missing file, libcap | Cc: | |
Guest type: | Linux | Host type: | Linux |
Description
Tried to run the new VirtualBox 2.1.0. Got the following error:
error while loading shared libraries: libcap.so.1: cannot open shared object file: No such file or directory
Searching my system via "find / | grep -i libcap" returns no file by that name.
Change History (8)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Are any of the pre-built binaries compiled with libcap.so.2? I've been trying to update the Gentoo package for VirtualBox, but would really prefer to use the newer, more secure libcap2.
comment:3 by , 15 years ago
AFAIR we compile against libcap1 on every distribution. Actually we need that library only very rarely (two calls to cap_set_proc()
in SUPR3HardenedMain.cpp and I plan to change these calls to using direct syscalls to prevent these library problems on Linux.
comment:4 by , 15 years ago
This problem occurred on Slackware 12. I found and installed the proper libcap and everything is working. It all just kinda caught me off guard - especially since this hasn't happened in the past like with 2.0.4.
comment:5 by , 15 years ago
I already explained it elsewhere: We need CAP_NET_RAM for ICMP support in guests on Linux hosts.
comment:6 by , 15 years ago
Frank,
Using direct syscalls will insulate you from the library dependency but might make you kernel-dependent. I got the impression from some of the lkml articles that this is a potential area for API churn, and the libcap interface is meant to insulate against that. I think the interface you're using might be stable enough that that's not an issue, just be sure you're not jumping out of the frying pan and into the fire.
I looked at the code yesterday. The calls you are using seem to be ABI-compatible between libcap1 and libcap2. I'm using a local symlink in the VirtualBox install directory (/opt/VirtualBox/libcap.so.1 -> ../../lib/libcap.so.2) to satisfy the linker and everything seems perfectly stable (for several days now). I know this is generally a bad idea, but since Gentoo does not have a libcap1 package available in portage any longer this works for me.
Maybe a better long-term solution is to wrap the binary-only pieces in a partially-compiled and linked package that does not reference any system libraries, then allow the user/disto maintainer to finish the build and link to the proper libraries for their system?
comment:7 by , 15 years ago
Summary: | libcap not found → libcap not found => Fixed in SVN |
---|
I don't think that partial compiling is applicable. In r15871 I've changed the code to use direct kernel calls to prevent the dependency to libcap
. We need only one system call (capset
). If the kernel interface would change, we would adapt that code as well. This is actually not much different as compiling against another libcap library (which would be necessary if the kernel interface changes).
comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Which distribution of Linux are you using? This is somewhat important as, for instance, Gentoo has progressed past libcap v1.x onto v2.x while RHEL/CentOS are still running the older versions. It'll also let people ask intelligent questions and, possibly, let you know how to obtain and install the appropriate package.