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.