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)

-----

Hacking Bluetooth Modules in Fedora 17 Linux

Having figured out how to successfully build the original source package of the Bluetooth modules downloaded online (see my older post on how to build), now we can head to hack those modules in order to customize certain Bluetooth functionalities on demand (as is actually, at least one of many others, the reason why we wanted to build the source package instead of downloading the executable in the first place).

To hack the Bluetooth modules and make it really effect for ordinary users, we need both categories of module - the kernel module and the user module. While the tricks required to build the kernel modules ca be found in the older post on how to build, building the latter on the same platform (AMD64, Fedora 17 Linux) has been straightforward at least for myself(your report of troubles in building the user space modules of Bluetooth, i.e. as downloaded from bluez.org, is welcome to be put into the comments of this post). Remember, however, as was somehow seemingly required, you need to "sudo" the execution of the common sequence of "./configure" -> "make" -> "make install" if you are not logged in as the root directly.

Now following things to be followed, no big deal, just the below listed,

1. Having successfully built the kernel modules should have given you a group of module binaries (.ko files) that has been moved ("installed") to the directory of "/lib/modules/`uname -r`/updates" by default, where subdirectories include the following together with example, but not all, enclosed files :
driver[/btusb.ko],  net[/bluetooth/{rfcomm.ko, bnep.ko}], and net/[bluetooth.ko]. 

* if you have not yet successfully got these files, you have not yet successfully built the kernel module then. Check again you have really followed and went through successfully the following steps before getting back again to the older post on how to build:
under the top source directory, do
"make clean" -> "scripts/selectdriver bt" -> "make install-modules"

2. before you can "mount" the newly built kernel module for bluetooth above, make sure you "dismount" the currently mounted one as the system has done while booting the kernel by default. Do these:
"killall -9 bluetoothd" -> "sudo modprobe -r bnep" -> "sudo modprobe -r rfcomm" -> "sudo modprobe -r btusb" -> "sudo modprobe -r bluetooth". An alternative to "modprobe -r" could be "rmmod".

* note if the bluetoothd (see below for more about it) is still running, you will get "cannot remove module xxx, xxx is busy/in use" when you are doing the aforementioned "dismounting" steps.

* note that the btusb.ko module is directly associated with the "bluetooth icon" on the toolbar of the desktop , which is presented there by default. So when you killed this module, that icon disappeared. In return, you can use the disappearance of that icon as a simple flag that this module has been removed successfully.

* If you still had trouble removing them, play the trump now:
"sudo init 3" -> "log in a root" -> "do the same series of modprobe -r"

3. Having successfully built the user space module should have given you a set of binary executables and objects (lib files) besides documentation related files to the directory you have indicated when doing "./configure" before. Check the installation directory for such subdirectories as that includes the following together with example, but not all, enclosed files :
bin[/hcitools], sbin[/bluetoothd], ....

Here we actually are concerned about the bluetooth daemon server bluetoothd only, as is to be running in the user space to bridge the bluetooth applications and the underlying bluetooth kernel modules.

4. Now start mounting your own hacked modules and make them effect by following steps:

1. "sudo mv /sbin/bluetoothd /sbin/bluetoothd.org" (just back up the original one in any way you prefer)
2. "sudo cp $installDir/sbin/bluetoothd /sbin/" (this is critical, directly running this daemon from the $installDir", at least when the "installDir" is not the one taken as default, has fallen to failure for me)
3. "sudo /sbin/bluetoothd [-n] [-d]"
4. "sudo modprobe bluetooth,bnep,rfcomm,btusb"

Now you should have been working with your hacked bluetooth modules.

* using "-n" to run bluetoothd in a non-daemon will show you the running log that can give you a sense of how the user modules get loaded and run; further, the addition of "-d" to the command line can provide you even more details of the internal dynamics of the user space code.

* "dmesg -T | grep "bluetooth" can give you running logs of the kernel module, about their being loaded and run.

Enjoy hacking!

Nikon D5100 16.2MP Digital SLR Camera with AF-S DX Nikkor 18-55mm f/3. (Google Affiliate Ad)

Build Bluetooth Kernel Module in Fedora Linux

Prelude:
If you do not encounter issues like one of the following, you are free to leave now so as to avoid a waster of time reading more below.

Download  Linux Bluetooth kernel module source code

Can not compile Linux Bluetooth kernel module

/sbin/modprobe: invalid option -- 'l'


========================== Start =====================================

Although this practice was with Fedora Linux 17, the following instructions should still do the tricks for building the Compat bluetooth kernel module for Linux with kernel version of 2.6.x or above.

NOTE: this post is not about playing with the user space code that you may find on the bluez.org official site http://www.bluez.org/download/

1. download kernel code for the bluetooth module
This should be ported together with the kernel itself, but in case you have not yet had it on hand or been unable to find the source code, download from the site below

https://gforge.ti.com/gf/download/frsrelease/802/5435/ti-compat-bluetooth-2012-02-20.tar.gz

2. now once your followed the steps indicated on http://processors.wiki.ti.com/index.php/Open_source_Wireless_Connectivity_Bluetooth_components#Bluetooth_Modules, you will probably get stuck by the compilation with

make KLIB_BUILD=<Path To Linux> KLIB=${ROOTFS} install-modules

(Equivalence of it is to run "make bt" under the top source code directory.)

Error might be like some syntactical faults in the kernel headers this module depends on, and you may find you have no luck by applying the patch provided in the above site (http://processors.wiki.ti.com/images/8/8e/Compat-patch-zip.zip) , the only cure I had got that really was efficacious is to apply the following patch instead (thanks to the guy who posted it)
http://marc.info/?l=linux-wireless&m=132760196131230&w=2 (in case this link may be expired or moved away, I have pasted below)

This file was introduced in commit 2a11c8ea20bf850b3a2c60db8c2e7497d28aba99
and included in 3.1 and later kernels.  It includes <generated/autoconf.h>
itself, as well as some other definitions that are used elsewhere.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 include/linux/compat-2.6.h |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/linux/compat-2.6.h b/include/linux/compat-2.6.h
index c23e94a..3ccd051 100644
--- a/include/linux/compat-2.6.h
+++ b/include/linux/compat-2.6.h
@@ -2,7 +2,9 @@
 #define LINUX_26_COMPAT_H
 
 #include <linux/version.h>
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,1,0))
+#include <linux/kconfig.h>
+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
 #include <generated/autoconf.h>
 #else
 #include <linux/autoconf.h>
-- 
1.7.4.4

(Copy it into a file named newpatch, say, and then apply it by "patch -p1 newpatch")

Thereafter, you should be able to get through "make bt" successfully".

3.  However, when you get to "make btinstall" or later "make btuninstall" to toy around the Bluetooth loading or unloading, you can get more annoying warnings like:

/sbin/modprobe: invalid option -- 'l'

It seems not critical but will block the normal process of "installation" from being complete hence unsuccessfully installation of the new Bluetooth module you just made.

To get rid of them (I am showing you the reasons behind it since you may be interested more in the solutions right now, please Google that if you are indeed intrigued with that),  use the following trick
(this is came up with on the basis of what was earlier posted by Artem Chekunov on http://comments.gmane.org/gmane.linux.kernel.wireless.general/87040)

touch /sbin/modprobe.sh

and then put the following into it and save.

--------------------------------------------------------------------------

#!/bin/bash

if [[ $1 == -l ]]
then

if [ -z $2 ]    
then

 find /lib/modules/$(uname -r) -name '*.ko' | \

 sed -e "s#\/lib\/modules\/$(uname -r)\/##g"
else 

 find /lib/modules/$(uname -r) -name '*.ko' | \ 

 sed -e "s#\/lib\/modules\/$(uname -r)\/##g" | grep $2
fi

else
/sbin/modprobe $@
fi

exit 0 

---------------------------------------------------------------------------

Note the last line I added (besides changes made somewhere else) is important to make sure that "make" can run completely through all expected steps.

Then do the following more steps:

chmod +x /sbin/modprobe.sh
alias modprobe=/sbin/modprobe.sh
echo "alias modprobe=/sbin/modprobe.sh" >> /etc/bashrc

cp Makefile Makefile.save
sed -i -e 's/^MODPROBE.*/MODPROBE := \/sbin\/modprobe.sh/g' Makefile

Now do what you like.

========================== End =====================================

Cracking problems during installation of FreeWRL under Fedora 13

Starting from : http://freewrl.sourceforge.net/install_Linux.html

Can not find the gdk-pixbuf library or version is lower than required

One more, maybe last in the nasty complaining list for building GTK+-2.22.1, prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it:

 1. yum -y reinstall gdk-pixbuf-devel.x86_64 gdk-pixbuf.x86_64
oops, no luck this time, ./configure of GTK still grouses there for missing it (on some platforms, this reintallation could only get the 0.22.0 version, for instance)

( if it wors ok now for you, stop here and congrutulations to you!)

2. download and built on source package

But gdk-pixelbuf-2.0 can NOT be found,  how repulsively this costly trivial steps end like this!


Finally, it is a conclusion:  you should build gtk-2.4, where gdk-pixbuf-2.0 will be included inside!!


ok, what else could we do but to follow it :

1.
go ftp://ftp.gtk.org/pub/gtk/v2.4/ :

wget ftp://ftp.gtk.org/pub/gtk/v2.4/glib-2.4.7.tar.bz2

bunzip glib-2.4.7.tar.bz2 && tar xvf   glib-2.4.7.tar.bz2

cd glib-2.4.7.tar.bz2 && ./configure && make && make install


pkg-config  --modversion  glib-2.0
2.4.7

2.
wget ftp://ftp.gtk.org/pub/gtk/v2.4/pango-1.4.1.tar.bz2

same steps to install pango 1.4.1 as above

*** 'pkg-config --modversion glib-2.0' returned 2.4.7, but GLIB (2.26.1)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error:
*** Glib 2.4.0 or better is required. The latest version of
*** Glib is always available from ftp://ftp.gtk.org/.

Overriding/overwriting and Overloading

It is often asked how overriding/overwriting differs from overloading and there are many posts online to answer related questions. Here I am summarizing the difference between them to give an overview as much complete as possible.

(1) Overloading provides multiple signatures for the same method in a single class, with the return value being not seen as part of the signature of method; Overriding provides a different implementation of a method inherited from a base type.

(2) Overloading is decided at compile time and overriding is decided at runtime, Overriding is basically the point of polymorphism by inheritance.

(3) Overloading lets you define a similar operation in different ways for different data, Overriding lets you define a similar operation in different ways for different object types.

(4) Using overloading and overridding, you can acheive the concept of polymorphism. Polymorphism means "one name, multiple forms". Using one name u can do multiple of actions. Method overloading is a compile time polymorphism and Method Overridding is a runtime polymorphism. Compile time polymorphism means compiler knows which object assigned to which class at the compiling time. Runtime polymorphism means compiler didn't know at the compile time, it only knows at a run time.

(5) Overriding method appears in subclasses, having the same name and same parameter list as a superclass method. The access modifier for the overriding method may not be more restrictive than the access modifier of the superclass method.

=====================================

Similar to this topic, there is a differentiation between shadowing and overriding, found at

http://msdn.microsoft.com/en-us/library/ms172785(v=vs.80).aspx