Netrek on Fulong

Introduction

So, one of the games that I loved back when I first started out using a unix based OS (back then it was either SunOS or HPUX) was netrek. I was introduced to it by Rob Forsman back then, as he was a major developer for it. So I figured it would be an interesting thing to get working on the Lemote Fulong

Sources

• Cow Version 3.2.3
• Imlib2
• Freetype 1.3.1

Creation

The first problem I ran into was that this software required the use of Imlib2. OK, not a problem, except that there are no packages for Imlib2 in the Lemote distribution of Debian, so I had to grab the tarball and go from scratch.

I did this only to find that Imlib2 in turn depends on libttf.so, which is a part of the freetype package. Now, interestingly enough, freetype has since given up on the creation of libttf, and now puts everything into libfreetype. So it looks like Imlib2 is ancient as well since it depends on something that is also ancient.

Once these were built, the actual build of netrek went fine, though there were a ton of warnings. I am not sure if this is a normal thing or not since I have not built netrek on a standard x86 box.

So here you have it:

kiona:/home/jka/netrek-client-cow-3.2.3# file netrek
netrek: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), 
not stripped

Freetype

Configure went fine, but when it came time to make, I ran into the following problem during the testing section of the build:

gcc -c -I. -I/home/jka/freetype-1.3.1/test/arch/unix/../.. -I.. -I/home/jka/freetype-1.3.1/test/arch/unix/../../../lib 
-I/home/jka/freetype-1.3.1/test/arch/unix/../../../lib/extend -g -O2  -Wall -pedantic -ansi  -DX11 
-DLOCALEDIR='"/usr/local/share/locale"' ftdump.c
ftdump.c:172:1: error: pasting "." and "glyph_object" does not give a valid preprocessing token
ftdump.c:182:1: error: pasting "." and "first_instance" does not give a valid preprocessing token
ftdump.c:191:1: error: pasting "." and "second_instance" does not give a valid preprocessing token
ftdump.c:201:1: error: pasting "." and "face_object" does not give a valid preprocessing token
ftdump.c:202:1: error: pasting "." and "glyph_object" does not give a valid preprocessing token
ftdump.c:203:1: error: pasting "." and "second_instance" does not give a valid preprocessing token
ftdump.c:863:1: error: pasting "." and "initial_overhead" does not give a valid preprocessing token
ftdump.c:882:1: error: pasting "." and "face_object" does not give a valid preprocessing token
make[1]: *** [ftdump.o] Error 1
make[1]: Leaving directory `/home/jka/freetype-1.3.1/test'
make: *** [tttest] Error 2

Alright... well then, let's get rid of the testing portion of freetype. It isn't like we need it, right? :)

12c12
< all: ttlib ttpo
---
> all: ttlib tttest ttpo
34c34
< #     cd $(FTTESTDIR); $(MAKE) -f $(MAKEFILE) install
---
>       cd $(FTTESTDIR); $(MAKE) -f $(MAKEFILE) install

Now it makes cleanly and we can install it.

Imlib2

Configure fired off fine and generated Makefiles without issue.

Of course, during the make, I get the following error:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I../libltdl -I/usr/local/include -I/usr/local/include -I. -I.. -I../src 
-I../loaders -g -O2 -c rgbadraw.c  -fPIC -DPIC -o .libs/rgbadraw.lo
rgbadraw.c: In function '__imlib_draw_polygon_filled':
rgbadraw.c:2328: error: label at end of compound statement
rgbadraw.c:2334: error: label at end of compound statement
make[2]: *** [rgbadraw.lo] Error 1
make[2]: Leaving directory `/home/jka/imlib2-1.0.6/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jka/imlib2-1.0.6'
make: *** [all-recursive-am] Error 2

Hrm... that kind of sucks... just what is wrong with these labels anyway? Well, as it turns out, because of the C specifications, if you jump to a label and that label doesn't have anything after it, it is a violation of the specification. Now, older versions of gcc apparently had no problem with this and just let it happen anyway, because it was a stupid restriction on labels in the first place. Apparently someone got all uppity about this and forced gcc to be bitchy about it, so now it throws errors and breaks the world.

The solution? Add a bloody semicolon on the next line after the label. Poof, empty command that doesn't do shit, but at least it satisfies the stupid specification.