BozoSort

Part 1 of my journey with Go! from Google.

Getting the Go! compiler up and running

Following Google’s installation instructions are fairly simple. One thing to keep in mind is that all three architectures are based on different compilers, and each compiler must be built for each architecture you wish to build to. A minor annoyance now, but it may turn out for better or for worse later on. Imagine building something for every architecture. You’d have to have to configure and build an entire compiler for every one of them, as well as deal with the clusterf**k of automake files that’s sure to ensue.

On to building as per Google’s instructions:
One thing to keep in mind, $GOBIN is not clearly explained like the other three env variables. I just set them like this:

export GOROOT=$HOME/go
export GOARCH=386
export GOOS=linux
export GOBIN=/home/[Me]/gobin


where [Me] is my own personal home folder. No, it’s not very clean, but I’m really way too lazy to do it the “proper” way. I’ll just wait for Go! compilers to end up in my distro’s repositories. Also, the above (specifically GOBIN and GOROOT) needs to be re-exported every time you reboot, other wise your computer forgets them and trying to compile your .go programs will result in missing packages and whatnot. So add those lines to your .bashrc or whatever file it is you choose which is run upon boot.

You will also need to add GOBIN to your $PATH, so throw that into your .bashrc (or whatever) at this time as well.

PATH=$PATH:$GOBIN


To make these changes take place without rebooting, do a simple

source ~/.bashrc


In acquiring the source files to build, Google recommends using some easy_install python crap. Just ignore that and install mercurial directly using your favorite package manager, and then use their command:
hg clone -r release https://go.googlecode.com/hg/ $GOROOT

to download the source files.

Making the Go! compiler

Firstly, make sure you have bison gcc libc6-dev ed make all installed using your favorite package manager.

Then, it’s time to build Go!:
Change to the src directory, and then start the build process:

cd $GOROOT/src
./all.bash


Remember, you’re going to be building a cross-compiler (even if you’re on a “native” machine) for the architecture you defined on $GOARCH. If you want different compilers, you have to change all your variables accordingly and build appropriately.

Onward to compiling!

As said before, each architecture uses an entirely different compiler (and linker).

Architecture	amd64	i386	arm
Compiler	6g	8g	5g
Linker	6l	8l	5l

In my examples, I’ll be using the 8g, or i386 compiler since my laptop has a dinosaur Pentium cpu.

Before compiling out program, we should probably write it first. You could be cool and just cat the following to a file, or you could be like me and open a favorite text editor (gedit in my case) and make files that way. Here’s the code for the “Hello World” that I used.

package main

import fmt "fmt"

func main()
{
	fmt.Printf("Hi\n");
}

I saved this as Test.go to my working directory. To compile, use:

8g Test.go

And then to link it:

8l -o Test Test.go

The “-o” switch tells the linker to call the output file “Test” rather than the default “8.out” which is how the google guide leaves it. I like properly named output files that can exist in the same directory without being overwritten.

Lastly, we run the program with the familiar:

./Test


As for output, I got the expected:

[Seth@SFedora GoFiles]$ ./Test
Hi


If you use Webmin to manage your server, you will eventually come across upgrades which will seem to ‘break’ your install. After upgrading, you’ll lose the ability to log in, and it seems as though the whole thing is just borked. In reality, you just need to restart the webmin daemon. Since this only happens when you reboot or start it manually, you’ll need to either reboot or start it manually.

At the command line, type (as root):

# /etc/webmin/start

After logging in you can verify the upgrade was successful and make sure that webmin starts upon system boot, just in case.

There are existing instructions on how to connect an Ubuntu (or any Gnome-Network Manager) machine to the University of Texas restricted campus wifi, but they are several years out of date. The interface has changed quite a bit over the past few years, and now no longer provides some default settings that the UT instructions relied on previously.

Here are the proper settings for the “updated” Network Manager:

Wireless Security: WPA & WPA2 Enterprise
Authentication: Tunneled TLS
Anonymous Identity: anonymous
CA Certificate: [the one you downloaded]
Inner Authentication: MSCHAPV2
Username: [your UT EID]
Password: [your corresponding password]

There are also instructions on the UT Helpdesk site for using wpa_supplicant to get yourself connected, but I strongly recommend not using that. I also don’t recommend using KDE’s network manager, as it sucks. hard. I have never tried to use Wicd, but I imagine if you use the same settings it will work just as well.