Building and Extending VirtualBox Source Code in Fedora Linux

The following practice was done in Fedora 17 Linux on an AMD-64 arch. If you are playing around VirtualBox in Ubuntu, you may find it much easier than the following talks about.

Of course, the reason why you wanted to build the source package of the Virtualbox instead of downloading the executable by automatical installation provided by such and such an "installer" is very likely to be your desire to extend or develop on the current VirtualBox distribution. I was doing this for extending it to include a performance monitor for the VMM at the core.

Now go ahead building the source package in the first place. No exhaustive details, just critical steps to work around traps and annoying errors you might have got stuck on, since I have no intent to write tutorial for building VirtualBox in Linux given the existing tutorial maintained on the official site of the developers of VirtualBox. See "Linux build instructions" in there.

1. failure in getting through the first-step "./configure". Here are the cures:

• for openWatCom, if you can not build from the source code successfully within at most 20 minutes, forget about that daunting way of doing it.  Instead, just install it using the installer found here to save yourself!
• for "LIBIDL"'s missing, sudo yum -y install LIBIDL-pluginbase-devel (the name might not be exactly as this, correct it as needed)
• for Qt4, compiling the source code rather than just installing the executables to install. Using the opensource-everywhere source package (found here) is recommended.
• * this may take long, be patient and after it is finished, add the directory holding the "qmake" executable to the environment variable "PATH" and make it take effect before doing "./configure" again.
• for PulseAudio, use the disable flag corresponding to it as an option to the "./configure" launch.
• upon failure to find "lstdc++", "whereis libstdc++.a" and then copy it from where you found it to the standard place "/usr/lib64"
• For missing headers for "32-bit support", using "--nonfatal" option provided with the "./configure" itself. By doing this, we simply ignore, and hence sacrifice, the support of 32-bit additions by the VirtualBox
• * For other errors, put it into the comment area of this post. I will try to help with them.

2.  failure in getting through the "make" step (actually "kmk" instead of "make", a KBuild variant of the GNU make). Here are the other cures:

• for the repulsive error like "spec failure: g++: invalid/unrecognized option "-m"", do "kmk -ik" anyway but keeping the error log by appending " 2>errors 1>&2" to it
• grep "g++: " errors > makeup.sh and then replace all "g++" with "g++34" (under Fedora 17, g++34 is installed by default and otherwise I presume you have it by any means. Or I am not sure for now how to get this hurdled bypassed). 
• do the brute-force "complete" compilation by "kmk -bBik all"
• And, now run "sh makeup.sh". If things are done, you should be able to locate the "VirtualBox" executable under the $installDir/linux.x86/release/bin directory, run it and enjoy your success. 
• Otherwise, you will need go back to the "errors" file to find other failures in issues other than the "invalid -m options with g++", for example some compilation errors in your own hacking code.

3. finally, failure in launching the newly built Virtualbox frontend (the backend, VBoxSVC and XCOM service will automatically be boosted up when the first frontend gets started). Here are the final cures:

• for messages complaining about "can not load vbox driver" or something like that when you are trying to start a virtual machine, get back to your terminal and do "sudo modprobe vboxdrv". If this does not do the trick, using insmod directly by "sudo insmod $path/vboxdrv" where "$path" indicates where the vboxdrv.ko file is located. You can get the path by "find -name" or "locate" followed by "vboxdrv.ko"; Alternatively, you can simply do "sudo kmk load" under the top source code directory to get this step done as well.
• for complaints like "driver is not accesible", which may pop up at the time of starting a VM too, do "sudo chmod a+rwx /dev/vboxdrv" - by default, the vbox driver should have been placed in /dev/

Brother HL-2270DW Laser Printer (Google Affiliate Ad)

-----