APPEAL FOR HELP from amd64 users

Post by **winston** » Fri Jan 27, 2006 10:57 am

All you lucky AMD64 people out there...

- Can you set up a build environment to build Oolite from source?
- Can you package a minimal set of 64-bit GNUstep and SDL etc. libs?
- Can you install and build an Autopackage?

If so, the Oolite-Linux project wants YOU!

It would be really really nice to have a native amd64 install package (both tarball and autopackage) for the final version of 1.62. Unfortunately, I don't have any suitable hardware to do it myself.

If you're willing to be the maintainer for the amd64 stable version, please step forward.

TedJ · Post by **TedJ** » Mon Jan 30, 2006 3:44 am

Damn. I did have a new AMD64 system in my (near) future... right up until my fusebox at home went china syndrome on me last week, requiring a full rewire of my house. $7000 AUD later, and my upgrade plans go back onto the backburner for the forseeable future.

Guess I'll be sticking with my old PIII 866 clunker for a while yet.

lex_talionis · Post by **lex_talionis** » Mon Jan 30, 2006 5:30 pm

TedJ wrote:
$7000 AUD later...

OW.

Grid · Post by **Grid** » Fri Feb 03, 2006 5:04 am

If someone can point me to some basic documentation on what is required, I'd be willing to give it a shot.

Post by **winston** » Fri Feb 03, 2006 8:41 am

http://wiki.alioth.net/index.php/Running_Oolite-Linux

has a brief section on building it.
See the development site http://oolite-linux.berlios.de (go to the project page) and you can get the source (as an SVN tree).

Basically, an installer should contain:
- the uncommon dependencies: a stripped down GNUstep compiled for the platform (you can strip it down until it's just 3 megs or so).
- the SDL libraries
- a few other little bits and pieces that don't seem to come as standard on all distros.

(If you look at the x86 installer, in the oolite-deps directory, you'll see the kind of thing that needs to be installed).

Enverex · Post by **Enverex** » Sun Aug 20, 2006 1:53 pm

Just working through it now. Just some minor warnings on compilation:

Code: Select all

src/SDL/main.m:22:16: warning: extra tokens at end of #ifdef directive
src/Core/PlayerEntity.m: In function ‘-[PlayerEntity setGuiToMarketScreen]’:
src/Core/PlayerEntity.m:6015: warning: pointer type mismatch in conditional expression
src/Core/PlayerEntity.m:6017: warning: pointer type mismatch in conditional expression
src/Core/Universe.m: In function ‘-[Universe obj:dump]’:
src/Core/Universe.m:547: warning: pointer type mismatch in conditional expression
src/Core/Universe.m: In function ‘-[Universe shipsForSaleForSystem:withTL:atTime:]’:
src/Core/Universe.m:7311: warning: pointer type mismatch in conditional expression
src/Core/ScriptCompiler.m: In function ‘-[NSMutableString(OOScript) replaceString:withString:]’:
src/Core/ScriptCompiler.m:41: warning: passing argument 3 of ‘replaceOccurrencesOfString:withString:options:range:’ makes integer from pointer without a cast

Enverex · Post by **Enverex** » Sun Aug 20, 2006 1:58 pm

It compiled and seemed to be running fine (sound, music, graphics all fine) until my ship got blown up. At the point it should have blown up the game just crashed instead, dissapeared with the following appearing in the terminal:

Code: Select all

2006-08-20 14:56:10.645 oolite[16649] DEBUG ** resetting track for <ShipEntity Cobra Mark III 100> **
Floating point exception

Post by **winston** » Sat Aug 26, 2006 8:00 am

Can you build it as a debug build (make debug=yes then debugapp oolite.debug/oolite) and have it crash again? Then find out what line of code it crashed on and what was zero but shouldn't have been (it might actually be a bug that affects ia32 as well, but I'm away this weekend so can't check it out).

Incidentally, there have been quite a few divisions by zero which seem to have no deleterious effect on PowerPC but will cause Intel builds to croak with a floating point exception.

Post by **Getafix** » Tue Apr 01, 2008 1:51 pm

Since this is an old post, I was wondering if there is still a need for a maintainer for the amd64 stable version.
I am willing to help on that matter.

Cmdr. Maegil · Post by **Cmdr. Maegil** » Tue Apr 01, 2008 3:23 pm

Hello, Getafix, and Welcome to the Friendliest Board This Side of Riedquat.

I'm not with the development team to say if there is still a need for a specific AMD64 build, but I since Oolite is an evolving entity, programming wizards and code druids are always in need.

BTW, if Toutatis ever threatens to drop the sky on your head, just follow the spacer's ethos: Q-mine the bastard and jump to another system!

Post by **Getafix** » Tue Apr 01, 2008 4:27 pm

Ahoy, Cmdr. Maegil and thank you for your warm welcome.

I'll first start looking into packaging Oolite. In the meantime, however, I would really appreciate the acquaintance of other amd64 maintainers (if any), so as not to reinvent the wheel. I hope that this post is a good point to start.

BTW, Q-mining Toutatis is to be avoided, since I will need all his assistance in taming the Ubuntu amd64 distro.

drumz · Post by **drumz** » Wed Apr 02, 2008 3:27 am

I took the following steps to get Oolite to compile for 64 bit arch:

Install GNUStep.

Copy jsautocfg.h from my 64 bit Firefox package to deps/Cross-platform-deps/SpiderMonkey/js/src.

Make SpiderMonkey with "make -f Makefile.ref"

cd to Linux_All_DBG.OBJ and move libjs.so to libjs.so.old, so Oolite will link against the static library (read this somewhere on the forums I think).

Now Oolite is almost ready, after a few more edits to the top level makefile:

Change

Code: Select all

oolite_LIB_DIRS += -Ldeps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -L/usr/X11R6/lib/

to

Code: Select all

oolite_LIB_DIRS += -Ldeps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -L/usr/X11R6/lib64/

in GNUMakefile so it picks up the proper 64-bit libs

I had to modify GNUMakefile.postamble as follows:

Code: Select all

ifeq ($(debug),yes)
        EXTENSION=debug
        SHAREDOBJ=shared_debug_obj
        SHAREDOBJ=obj
else
        EXTENSION=app
        SHAREDOBJ=shared_obj
        SHAREDOBJ=obj
endif

Not sure why, but my system places all of the object files in obj/ instead of shared_debug_obj/ or shared_obj/.

Post by **Getafix** » Wed Apr 02, 2008 10:56 am

Instructions on how to build for AMD64 debian have already been posted, by user Whisht, in this BB and can be found here. If any problems are encountered, while using "dpkg-buildpackage" for xulrunner source package, you can just manually create the file jsautocfg.h using the contents published by user Influence D in the same post.
It worked for me on Ubuntu 7.10 AMD64 Desktop.

Is there anyone in this BB that has built a native AMD64 install package? If not, who is maintaining the Oolite Linux distro (currently available is v1.65, and it's fine with AMD64) that can be found in the Ubuntu repository? I would like to help on that matter, if there is a need.

TGHC · Post by **TGHC** » Wed Apr 02, 2008 11:48 am

Welcome to the boards Getafix, please go ahead and contribute, IIRC most of the work on linux was done by Winston who has backed away from Oolite these days, he has a lot on his plate with the EBBS and other things.

I'm infamously known as being a total non techie, however I think I'm right in saying most of the wizard contributors have been mainly platform specific, ie Mac, PC or Linux, with a little cross fertilisation here and there. You will be the first CPU specific contributor AFAIK. All contributions and help are gratefully accepted so go for it matey.

Post by **Getafix** » Wed Apr 02, 2008 2:35 pm

Hi, TGHC. I will look into it. Just to clarify, when I use the term AMD64, I am referring to the Ubuntu AMD64 which is the linux distro for both AMD and Intel CPU's that are 64bit. I was planning to contribute for the Intel part since I have a 64bit Intel Dual Core.
Does this post refer to AMD CPU only or to linux 64bit distros in general?