Getting VirtualBox to run on Debian 6

I got sick of seeing the "Could not load the host usb proxy service verr_file_not_found" error message when starting VirtualBox. What was even more annoying was that it worked under Ubuntu 11.04 without any problems.

I am running VirtualBox version 4.1.4 r74291 and have installed the VirtualBox 4.1.4 Oracle VM VirtualBox Extension Pack (available here: https://www.virtualbox.org/wiki/Downloads).

After a bit of poking through documentation I found this page https://forums.virtualbox.org/viewtopic.php?p=33944.

Next tried adding the usb file system to fstab
1. Find the group id
$grep vbox /etc/group
vboxusers:x:121:g6ujj,ns
and as root, added the following to fstab:
none /proc/bus/usb usbfs devgid=121,devmode=664 0 0

Success! Or at least I now get a different error message "VirtualBox is not currently allowed to access USB devices. You can change this by adding your user to the 'vboxusers' group."

Checked my groups settings, and no: I wasn't a member of the vboxusers group (although I am an administrator - go figure!)

Logged off and on again and that did the trick.

Now I can enjoy the delights of testing under Windows XP again. Yes, I know I can run most of my cross-compiled code under Wine, but there is nothing quite like being certain, is there?

Burning images using a Mac

Some notes on creating bootable images using a Mac.
I have had recent need to create bootable images from iso files.
Burning a CD or DVD.
This is perhaps the easiest using OSX. Open the Utilities folder in Applications and start the Disk utility package.
Drop the iso into the left hand pane, insert your CD/DVD and hit burn. I'm a touch paranoid, and like to verify the file has burned correctly. This can take a while, so have a cuppa or check Facebook while you're waiting. The disk will automatically eject when finished.
Job done.
Creating a flash drive image
This also is quite easy, open a terminal window.

1. Convert the iso file into an img using hdutil.
   hdiutil convert -format UDRW -o ~/path_to_target.img ~/path_to_iso.iso
2. Run diskutil list to see what devices are currently connected.
3. Insert your flashdrive and type diskutil list again. On my machine I got /dev/disk2.
4. Unmount the disk
   diskutil unmountDisk /dev/diskN (N is the drive your flash device is called).

1. dd if=/path_to_image.img of=/dev/diskN
2. When done, eject the media diskutil eject /dev/diskN

Mission successful, go and have a cuppa.

Decision made

I've decided to go with Debian.
I thought I'd give Windows 7 a try, but the interface feels so slow and clunky compared with (pre-unity) Ubuntu. The task bar eats up so much screen space it was really annoying me!
I am just doing an install from the DVD, and will add the other packages I am interested in when I have a working system.
What joy: setting up my environment again this week. I'm so looking forward to it.
Having said that, I have barely cut a line of code this week, and am starting to get a little antsy about it.
Back to the install...

Goodbye, and thanks for all the fish

I never got the chance to meet Douglas Adams, and never got to tell him how much I enjoyed his books. I'm hoping that he won't mind my use of a line from his book as the title for this post.
This was, apparently, the last thing the dolphins said to mankind just before the Earth was destroyed by the Vogon constructor fleet. If you want to know more, you need to read the trilogy in five parts.
Although I would enjoy talking about the Hitchhikers Guide to the Galaxy universe, that's not what I'm going to vent about today.
I've been a happy user of Ubuntu for several years now, I don't even remember the version that I first used and have upgraded to the latest and greatest versions. I will admit to the occasional difficult install and having to do a fresh reinstall and recovering my files from backups.
I'm not even complaining about the new Unity interface: although I wasn't fond of it, I could become used to the different layout over time.
I got used to having the window buttons on the left (after all, that's where they are on my macbook). Even more amusing, after I found out how to put them back on the right, after a few days I reverted back to the "official" new Ubuntu position.
However, the 11.10 release just doesn't do it for me.
I tried performing the distribution update (which took quite some time) and rebooted to find the machine wouldn't boot. At all.
Thinking how glad I was that I had made a full backup, and copied my files to another drive I downloaded the ISO and burned to CD. Rebooted to find myself stuck in the Grub recovery mode and unable to persuade it to boot for me.
No worries, I thought, I burned a 11.04 build and booted from that. Also to find myself looking at Grub recovery. So I created a usb boot drive with 11.10 and booted successfully from that.
I copied my important files back to my partition, switched to dual monitors to find the desktop background white, and Firefox also was pure white.
Rebooted, and all seemed to be fine. Except that every now and again a window (Firefox, Nautilus or empathy) would become all white. Sometimes adjusting the size of the window helped, but often it made no difference until a reboot.
This morning, after leaving the machine on downloading podcasts, I was not able to log back on. ssh also wouldn't connect, so another reboot to see...
Nothing. A blank screen.
ssh'ing in gave me a desktop and access to nautilus, but not clue why the display on the laptop would co-operate and let me access email or the web.
So the point of all this rambling is to say goodbye to Ubuntu. Although it is interesting tracking down why applications misbehave, and at the moment I seem to have more time on my hands than I'm used to, what I really need from a machine is to reliably boot and let me get on with life.
It looks like I'm going to be spending some time hunting for a new distro to live with, and I suspect that I'm starting with Debian - my macbook is busy creating the flashdrive boot image for me and then I'm going to have the fun of learning a new distribution...

Who reads manuals?

Should I be disgusted with myself?

Instead of trying the man command to find out how to get the ssh fingerprint, I googled first.

I found this post, and copy/pasted into my command line and it did the trick: one ssh fingerprint in all it's glory. Then I thought a little, and typed in:

man ssh-keygen


Guess what? It gave me the options I needed. Isn't that a welcome surprise? Of course I do know how about the unix online manual options, I have no idea why I Googled first.

Who reads manuals, after all?

Backups and upgrades

I am taking the (big) risk of doing an update on my main laptop in upgrading it to Ubuntu 11.10.

Out of paranoia (and because I had a problem with the filesystem recently), I decided to do  a full backup of my home directory first.

Two days later the backup was complete. Not surprisingly, I had done some work on the machine and needed to do a backup again, but this time I just backed up the files that have changed.

Today is the big day: starting the upgrade process. I found it amusing that it might take some time to download the updates. Only might?

Currently using my MacBook, and (as always) it is taking me a while to get used to the different key layout.

It takes a little while to reprogram my muscle memory into finding the ~, | and # keys again. I am never sure if Apple actually looked at a UK keyboard before setting up their keyboards, but it is most certainly not following the standard.

For those slightly less trusting than me, how do you know if a backup is successful? The only way I know is to do a restore. Comparing the backup to the original only says the files have the same contents, after all. It does not mean that the backup will be able to be restored to your machine.

My usual method for upgrades is to buy a new hard disk for the laptop, do a clean install then copy my files over onto the new install. This time I have bitten the bullet and went for a direct upgrade.

A working setup

I appear to have cracked getting Codeblocks to create code that will run on both a Linux environment and Windows. The same project can be used to generate an OSX version of the application, although has to be separately created on my macBook.

The only extra bit would be to get the code to cross-compile and run under OSX from within Linux (the cherry on my cupcake).

The OSX build

This will only work (for the moment) natively using codeblocks.

• Add new build targets OSXDebug and OSXRelease based on the default Debug and Release setups.
• Change the compiler and linker to include the -arch i386
• In the post-build steps add the following

mkdir -p $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

cp $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME)

/usr/local/bin/dylibbundler -od -b -x $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME) -d ./$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/libs/

For Windows

Install the mingw cross-compiler

Download and compile a mingw windows version of the wxwidgets libraries. This took a while...

Go to Settings, Compiler and Debugger settings. Add a new compiler based on the gcc one. Change the toolchain executables to point to the mingw executables.

Add new build targets WinDebug and WinRelease.

Change the compiler to the mingw one.

Make sure you have included the .exe extension for output filename.

Change the wx-config to point to the version you have compiled.

Other foibles for the Windows cross-compile

Certain libraries may be needed for the executable to run on the windows machine.

In the post build steps, add the following

cp /usr/share/doc/mingw32-runtime/mingwm10.dll $(TARGET_OUTPUT_DIR)

cp /usr/local/i586-mingw32/lib/wxbase28_gcc_custom.dll $(TARGET_OUTPUT_DIR)

cp /usr/local/i586-mingw32/lib/wxmsw28_core_gcc_custom.dll $(TARGET_OUTPUT_DIR)

cp /usr/local/i586-mingw32/lib/libwx_base-2.8*a $(TARGET_OUTPUT_DIR)

cp /usr/local/i586-mingw32/lib/libwx_msw_core*a $(TARGET_OUTPUT_DIR)

What next?

• Having the compiler automatically generate an install routine for the windows (mainly to put the dll's into the windows system folder)
• Getting the Linux build to cross-compile for the OSX platform
• Writing an application that works across all three platforms

I'm not sure which of the three would be the easiest...

Further frustrations and a brief moment of joy

After getting the OSX code to compile and execute using OSX (and the codeblocks/gcc combination), my next plan was to get the code to compile under Linux.

I had set up my code in a dropbox folder so I could access the same codebase across all my machines, and booted my laptop running Ubuntu 11.04.

Codeblocks started, the targets for Linux added to the project and hit 'build and run'. I sat back to watch... Screens full of error messages, top of the list was

error: invalid use of incomplete type ‘struct wxFrame’

After going round in circles, checking that the include files were present (which they were) and a few other dead ends I ended up removing and re-installing the wxwidgets libraries. It felt like a desperation move, and oddly it worked.

My code now compiled and executed as expected under Linux. Feeling brave, I started investigating getting the code to work cross-compiling for a Windows target.

Mingw libraries and utilities installed, a test program put together (another version of the infamous "Hello, World!" application) and a Hello World message box running on my Windows VM.

Getting codeblocks to use the cross-compiler wasn't difficult, a new compiler setup copied from the gcc version and changing the toolchain executables did the trick (the only bit I'm not sure about is the debugger, but when the code is compiling cleanly I'll run through that set of options).

The only gotcha was that a set of libraries are needed to have the code execute on Windows XP (I don't have other options to test at the moment - at least not while Lynn is using her computer).

Back to making progress

Hopefully these won't be the famous last words type of progress...

In the OSX Debug and Release build options we need:

-arch i386 in the compiler and linker options

In the post compilation build add

mkdir -p $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

cp $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME)

/usr/local/bin/dylibbundler -od -b -x $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME) -d ./$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/libs/

The only thing that is (mildly) irritating is getting the cocoa application to execute when the ide is trying to run the code.

Next step: get the basic code to compile and execute on the Linux box, and following that cross-compiling for windows (not sure if there will be different variants for XP, Vista and 7 though). And after that? Creating a useful (or otherwise) application.

>About to switch machines. After tea (gammon with honey glaze mmmmm)>

Famous Last Words

In my last post in this enthralling series on getting a development enviroment that will produce code on OSX, Windows and Linux I said that the next step was to get the MDI code working using wxWidgets.

You probably can't hear the hollow laugh (followed by silent screams, as I am coding in Starbucks), and you might not be surprised that a repeat project build.... isn't working.

I need to backtrack and work out what has changed, and get the setup working properly again. It would also be nice to get the post build scripts working so that I don't need to hard code folder names into the project.

I'm going to persevere for today, but I need my dual monitor setup to get it working properly: that either means bringing the big screen with me, or coding at home.

If you listen carefully, you just might hear me scream later tonight.

Getting Closer

There are a number of logical steps required to build an application that will run under OSX.

The most obvious is that you need to compile the code. There are some hidden gotcha's if you're not using xcode or projectbuilder, however.

In my previous entry I commented on my discovery that you need to add a flag to the compile and link options "-arch i386".

This has allowed the code to happily compile and link, but when the application is executed it starts in the background and refuses to come to the front. No menus, and seemingly unable to accept focus.

Todays discovery has been getting the application to accept focus, this needed further changes to the way that my codeblocks ide is set up, as well as adding a new application to my system.

The dylibbundler is the new application. The main page says that dylibbundler is a small command-line programs that aims to make bundling .dylibs as easy as possible. It automatically determines which dylibs are needed by your program, copies these libraries inside the app bundle, and fixes both them and the executable to be ready for distribution.

But like everything, it wasn't quite as easy as running the command line utility.

Firstly the output directory was changed to myApp.app/Contents/MacOS/myApp

Then I added the following to the Pre/Post build steps:

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

/usr/local/bin/dylibbundler -od -b -x ./SRA.app/Contents/MacOS/$(TARGET_OUTPUT_FILE) -d ./myAPP.app/Contents/libs/

This now gives me a running application that can be brought to the front. Note that the text is wrapping, a copy/paste into codeblocks will help.

Now all I need to do is to get the code to load the text file and display correctly. That might just be a little more difficult than getting codeblocks and OSX to play nicely.

Update: a step I missed out was to set the Output filename for the build targets to point to the modfied file name. For my app I had to set it to bin/osx/Debug/Sim65.app/Contents/MacOS/Sim65.

Frustrations with computers

In my free time (hollow laugh), I'm looking at creating a couple of simple applications using Codeblocks and wxWidgets.

My primary development environment is a laptop currently running Ubuntu 10.10, but I was wanting to use the same tools on my MacBook running Snow Leopard.

Over the past few visits to Starbucks, I've been trying to get a default application from Codeblocks for wxWidgets to compile, and got some wonderful compile and link errors.

The problem, apparently, is that the compiler will generate 64 bit code by default, which does not seem to be supported by many libraries.

After much frustration, I pasted an entire line from the build log into Google, finding this site http://forums.codeblocks.org/index.php?topic=12968.0.

The recommendation is to add -arch i386 to both the compile and link options. And it seems to work.

At least now I have a custom compiled set of wxWidgets libraries and Codeblocks itself. Sigh.

Time to start cutting code.