hardening disabled, following the "Linux build instructions" from the Technical
docs:
https://www.virtualbox.org/wiki/Linux%2 ... structions
The build succeeds but a path related error follows when I try to run the
VirtualBox executable (detailed information later on). My question is (from the
following build commands) if I'm missing some install command or some
environment variable configuration after the build, due to the fact that I'm
trying to run the program from the build target directory.
Code: Select all
./configure --build-debug --disable-hardening
source ./env.sh
kmk
# Build and install the VirtualBox kernel module
cd out/linux.amd64/$BUILD_TYPE/bin/src
make
sudo make install
prerequisite packages for Ubuntu as the build is succeeding and I don't think
they're relevant to the problem.)
When running the build I get the following error:
Code: Select all
$ out/linux.amd64/debug/bin/VirtualBox
!!Assertion Failed!!
Expression: g_szrtProcExePath[0]
Location : /home/user/vbox-src/src/VBox/Runtime/r3/path.cpp(66) int RTPathExecDir(char*, size_t)
Trace/breakpoint trap (core dumped)
understand correctly) used later on to locate other executables, and this
particular assert is complaining because this global variable hasn't been
initialized (and it has been left empty).
If I do a release build (without the --build-debug) to avoid the assert (not
as solution but to investigate the problem further) I get an error which
could also (but I'm not sure) be related to a path not being resolved
correctly:
Code: Select all
Failed to initialize COM or to find the VirtualBox COM server. Most likely, the VirtualBox server is not running or failed to start.
The application will now terminate.
Callee RC: NS_ERROR_FAILURE (0x80004005)
distribution", which mentions the configuration of:
Although I understand they don't apply to this type of build (with thedefault pathes which are used by the VirtualBox binaries to find their components.
hardening disabled) I followed its instructions to see if that helped with
this issue but it didn't change the outcome. (I actually copied the
LocalConfig.kmk from the debian/ directory which had the same definitions.)