Difference between revisions of "Netrek on Fulong"
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Introduction== | ==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 | + | 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== | ==Sources== | ||
* [http://quozl.linux.org.au/netrek/netrek-client-cow-3.2.3.tar.gz Cow Version 3.2.3] | * [http://quozl.linux.org.au/netrek/netrek-client-cow-3.2.3.tar.gz Cow Version 3.2.3] | ||
| Line 10: | Line 11: | ||
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. | 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. | ||
| − | So I | + | 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: | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
===Freetype=== | ===Freetype=== | ||
| + | Configure went fine, but when it came time to make, I ran into the following problem during the testing section of the build: | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| + | Alright... well then, let's get rid of the testing portion of freetype. It isn't like we need it, right? :) | ||
| + | <pre> | ||
| + | 12c12 | ||
| + | < all: ttlib ttpo | ||
| + | --- | ||
| + | > all: ttlib tttest ttpo | ||
| + | 34c34 | ||
| + | < # cd $(FTTESTDIR); $(MAKE) -f $(MAKEFILE) install | ||
| + | --- | ||
| + | > cd $(FTTESTDIR); $(MAKE) -f $(MAKEFILE) install | ||
| + | </pre> | ||
| + | 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: | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| + | 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. | ||
Latest revision as of 14:56, 19 December 2007
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
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.
