Installing GCC on Eee PC: A Walkthrough

This is a step-by-step walkthrough of how to build and install latest GCC (4.3.2 at the time of writing) from source on Eee PC 900 model with pre-installed Linux. The steps for other models may be similar but there's no way I can test it now.

0. Why do I need a GCC?

Well, why not? I cannot bear the fact that Eee PC does not come with a pre-installed gcc, since this basically says, hey, we don't want you to build your own stuff on it. What a thing to do, considering that they have already provided the assembler (as), linker (ld), pre-processor (cpp), text editor (vim), GNU make, Perl, Python, and many more!

The system itself is Xandros based. No problem. But it's the stable release. Err, can't they take a little risk and provide more up-to-date software? Firefox is of version 2.0.0.14 after upgrading, for example, and "Check for Update" is disabled within firefox.

I may be able to use it to check email for now, but I felt the urge to take control. So here's what I did as a first step to extend the system.

1. Preparations

1.1 Getting a shell

I am a gnome user, so the user interface looks a bit like maze to me. The first thing I tried in my local retailer was to launch a console program. It took me a good 10 minutes to find a way. Basically you could open a file manager and press Ctrl-T, which would give you a full fledged Konsole. But I later learned that there's an easier way: Just press Ctrl-Alt-T on the main desktop interface and you will get an xterm.

1.2 Preparing directory

My 900 model comes with a claimed 20G solid state disk. It was divided into two partitions, one of them 3.7G mounted as / and and the other 14.7G mounted as /home. The first partition, being used mainly by the pre-installed system, already took most of the space on it. So it's not a good idea to directly install anything there. However, installing everything to user home directory is inconvenient, since you need to modify default prefix when building, and makes installation of binary packages more difficult.

My solution is to move the entire /usr/local/ in to /home, and create a symbolic link there to refer to the one in /home. The commands to achieve this are:

sudo mv /usr/local /home
sudo ln -s /home/local /usr/

1.3 Getting a binary gcc package

The fact that Eee PC does not come with a compiler makes things a bit difficult to bootstrap. To compile GCC, you need GCC :)

The solution is, naturally, to get a minimum binary package from somewhere first. I first thought Debian packages would work, but I was wrong. Debian packages are tagged with an extra string after the normal package name and version number to identify which release it belongs to. This creates dependency problems. After some googling I found the following method to get gcc-4.1.2 from a xandros repository.

First, add the following line in /etc/apt/sources.list

deb http://xnv4.xandros.com/xs2.0/pkg/ xs2.0-xn main

Next, update the list of available packages by

sudo apt-get update
sudo apt-get install xandros-archive-keyring

The second command is just to let the system accept the public key of the xandros repository. After that, install gcc and libc6-dev as follows

sudo apt-get install gcc
sudo apt-get install libc6-dev

These may prompt you to install extra packages, such as linux-headers, but that's fine, and it won't take too much space. After this I got a working C compiler.

2. Building GCC

A detailed instruction of how to build GCC from source can be found at http://gcc.gnu.org/install/. However, many of the steps and options are not relevant here. So I'm going to zoom in to those things that are not the default.

2.1 Download the source

Three packages will be needed. First is GCC itself, then GMP, and lastly MPFR. Links can all be found from the gcc instruction page. There are two things to note here. One is that you only need the source of all three packages. GMP and MPFR will be built together with GCC. Second, if you are not so keen to compile Ada and Fortran etc. using gcc, you can just get gcc-core and gcc-g++ packages, which will be about only half of the size of the full version.

After downloading the source packages, decompress them in the same directory. I used /home/user/sw/. Each of these packages will have their own sub directory (except for gcc-g++ and gcc-core, they will go into the same directory).

2.2 Building from source

Before you actually start to build, you need to tweak the directories a bit. Suppose you are in /home/user/sw/ (replace this by wherever you decompress the source files). Also, suppose you downloaded gcc-4.3.2, gmp-4.2.4 and mpfr-2.3.2. You can do the following.

mkdir build
cd gcc-4.3.2
ln -s ../gmp-4.2.4 gmp
ln -s ../mpfr-2.3.2 mpfr

After that you can start to configure GCC in the "build" directory as created above (building inside the source directory is not recommended as stated on the gcc webpage).

cd /home/user/sw/build
../gcc-4.3.2/configure

By default the installation directory prefix is /usr/local/, which can be changed by "--prefix=dir" parameter to the configure script. After that you can start to build and install it.

make
sudo make install

Verify that you are using the new gcc by "gcc --version". I had to exit the current xterm and launch a new one to do that because although /usr/local/bin is before everything else in $PATH, somehow when I run gcc it still runs the old version in the existing xterm window.

When VMware meets Ubuntu

VMware is a cool thing. Only after you have a few gigs of RAM and dual/quad-core, that is. Although it is a proprietary technology, it does have a free server version that is tremendously helpful to me, both in daily programming work and casual time-killing.

Ubuntu is another cool thing, which I enjoy using at the moment. But it has certain ``problems'' (or maybe ``features'' that I'm not used to). One of them pops up when I use VMware server 2.0 on Ubuntu 8.10.

In short, everything went fine (well, almost), except that I found my UP arrow key is gone, and my DOWN arrow key becomes the Windows key in my guest XP.

This was not a new problem. I had the same problem with previous versions of VMware and Ubuntu, but unfortunately forgot what the solution was. I had a one-line script that reads:

setxkbmap -rules xorg -layout "us" -model pc

which I remember solved one of the previous problems, but it didn't work anymore.

Googling on VMware and Ubuntu gives me a lot of information, so much so that I couldn't find relevant solution easily. Eventually I came across this howto:

How to VMWare Server 2.0 on Ubuntu 8.10

This basically says that adding the following line in /etc/vmware/config would solve the problem for VMware server (VMware Workstation requires a bit more work).

xkeymap.nokeycodeMap = TRUE

This one-line solution solved my keyboard problem. I'm really glad that someone took the trouble to write this howto to help people like me, who have problems remembering every detail.

Fine Tuning Locale in Ubuntu GNU/Linux

http://isis.poly.edu/~qiming/fine-tuning-ubuntu-locale.html

0. Background

A few years ago, I was quite frustrated in configuring locale settings in Debian when I switched from RedHat (not that it was any easier for RedHat), so much so that I ended up writing my own mini howto on it, hoping it would be useful to folks like me.

I also tried Gentoo for a couple of years, but gave up the idea of compiling everything from the source and the long process of installation (I could have used the binary packages but that would sort of defeat the purpose, wouldn't it?). Configuring locale in Gentoo was quite straight forward, though.

Recently I lean more on Ubuntu, mainly for its effortless installation and configuration processes. Although I lost a little of control as what should and should not be installed on my system, but with cheap hard drives and CPUs today, that seemed to be a reasonable trade-off.

1. Locale configuration problems in Ubuntu

Locale configuration in Ubuntu was, as in Gentoo, quite straight forward, provided that you use the default gdm, since it allows you to specify a locale at the login window, and Gnome handles locales pretty nicely. For example, scim would be run (and working nicely) when I chose "zh_CN.UTF-8" as my locale. It should be pretty much the same for kdm and KDE but I didn't try.

However, a couple of little tricks I used to play with Debian wouldn't work in Ubuntu. For example, in Debian I could have set the locale to "C" and still have scim working on my browser and gnome-terminal, whereas in Ubuntu scim simply wouldn't work that way.

Also, when I set the locale to zh_CN, I lost control of menu displays and error messages. Although it wouldn't hurt to read error messages in Chinese, it sometimes requires a bit of guess work to decipher what they really mean, especially those errors and warnings emitted from gcc.

Ocasionally you would need to copy/paste the messages to your browser to google about a solution to your problem, and error messages in Chinese (which is not standardized in anyway) just wouldn't help.

Most importantly, when you want to view man pages, having a locale other than "C" could make it complain and refuse to work. Same goes for programs like aspell.

In Debian I could put something in /etc/X11/Xsession.d/ to fine tune the locale settings (as I explained in the mini howto) But it didn't seem to work in Ubuntu (at last for for some release versions that I tried). In some cases I could work it around using the enstart.sh script as in the mini howto, but it's troublesome.

2. Fine Tuning

In the end, I figured out that /etc/environment is the right place to place the locale settings. Basically I inserted the following lines into the file but leave "LANG" and "LANGUAGE" unchanged:

LC_MESSAGES="C"
LC_COLLATE="C"
LC_CTYPE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"

(EDIT: Actually, only LC_MESSAGES is required in most cases. Putting all of them here may confuse Ubuntu as I recently found out.)

After that, log out of Gnome (which seems to have the side effect of restarting gdm, otherwise I may have to restart it manually), and log in back again, and menu items, error messages, man pages, etc., would be displayed in English, without affecting scim.

A minor (but surprising!) problem is that the /etc/environment file does not support usual variable substitution as in a shell script. So I cannot put something like

ENCODING="C"
LC_MESSAGES=$ENCODING
...

as I did in the mini howto. What happens to the Least Surprise priciple, I wonder.