Oolite Bulletins

For information and discussion about Oolite.
It is currently Sat Aug 30, 2014 8:10 am

All times are UTC




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: GNUStep Upgrade
PostPosted: Tue Oct 09, 2007 5:13 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Sun Dec 03, 2006 9:07 pm
Posts: 341
I am running 1.69.1 build 1155 - cannot compile any later builds because of the UTF-8 problem which I haven't solved yet.

Today the new version of GNUStep was released for Debian Unstable. Quite reasonably it wants to uninstall Oolite, which was compiled against the older version.

My question: If I upgrade GNUstep and recompile and reinstall Oolite can I expect problems? I only have GNUStep to run Oolite so there is no upgrade pressure.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 09, 2007 6:48 am 
Online
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral

Joined: Wed Feb 28, 2007 7:54 am
Posts: 3836
There have been a couple of problem reports on the Oolite Windows build with GNUstep 1.13.1. Not certain how Linux would be affected, but if you are running SVN 1155, you should be fine with what you already have. I am generally of the opinion that unless the new versions have something that is absolutely needed, stick with the tested, working older ones.

However, if you have to build the most recent versions on SVN (assuming that the UTF-8 problem gets resolved), you will have to upgrade to GNUstep 1.13.0 in order to have debug support. Older GNUstep versions do not define some required streaming objects.

[Edit: Corrected sentence to reflect what I meant to say at the first place.]


Top
 Profile  
 
 Post subject: Re: GNUStep Upgrade
PostPosted: Wed Oct 10, 2007 9:21 pm 
Offline
Above Average
Above Average
User avatar

Joined: Sun Jun 24, 2007 7:29 pm
Posts: 31
davcefai wrote:
I am running 1.69.1 build 1155 - cannot compile any later builds because of the UTF-8 problem which I haven't solved yet.

Today the new version of GNUStep was released for Debian Unstable. Quite reasonably it wants to uninstall Oolite, which was compiled against the older version.

My question: If I upgrade GNUstep and recompile and reinstall Oolite can I expect problems? I only have GNUStep to run Oolite so there is no upgrade pressure.


Yes it would be fair to expect trouble. ATM I have the GNUstep versions pinned, and am running a 'frankenbuild' of SVN 1156, with selected bugfixes applied (like the trumbles crash.). Please note I'm not doing this in the 'Debian' way (with the controlled application of a patch), but by physically just updating bits of the source.

What we really have to hope for is a 1.70 stable release and the re-emergence of the / a Debian maintainer to sort this out. :) But as I said, pin the old GNUStep, use SVN 1156, the other changes mentioned, and cherry pick the non-js and trivial bug fixes...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 11, 2007 4:34 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Sun Dec 03, 2006 9:07 pm
Posts: 341
Unfortunately what you say in the last para is currently beyond my abilities. Moreover as I am handling the last stages of a big project at work my mental energies are at quite a low level when I get home so I have to put off learning C programming for quite a while.

Where I am stuck in building Oolite is:

I get the UTF-8 error when I run the game compiled using dpkg-buildpackage.

There is libmozj source in the SVN. I have compiled it separately as well. However I am not sure what to do then.

If I downgrade libmozjs might this overcome the problem?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 11, 2007 5:33 am 
Offline
Above Average
Above Average
User avatar

Joined: Sun Jun 24, 2007 7:29 pm
Posts: 31
davcefai wrote:
Unfortunately what you say in the last para is currently beyond my abilities. Moreover as I am handling the last stages of a big project at work my mental energies are at quite a low level when I get home so I have to put off learning C programming for quite a while.

Where I am stuck in building Oolite is:

I get the UTF-8 error when I run the game compiled using dpkg-buildpackage.

There is libmozj source in the SVN. I have compiled it separately as well. However I am not sure what to do then.

If I downgrade libmozjs might this overcome the problem?


I'm hung up at the same place-- If I'm reading things right the solution is to either rebuild libmozjs for Debian (beyond my fear and commitment threshold), or to statically build OoLite with the libmozjs provided as a .deb (which I have no idea how to do). Simply building vs. the libmozjs headers provided won't work as long the actual library doesn't have the required support. (You can point the GNUMakefile at the included mozjs. What has to be done is to statically link the library in the .deb, or to update Debian's libmozjs, AFAIK.)

Just for the record-- SVN rev 1156 with the older GNUStep was the last one that built well against Debian. (After that I've just been scooping trivial bugfixes.) If I get a good free day I'll take a more serious whack at it...


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 14, 2007 1:19 pm 
Offline
Mostly Harmless
Mostly Harmless

Joined: Sun Oct 14, 2007 12:47 pm
Posts: 3
Location: Ireland
Okay this is how I got oolite to build on debian last night (I might be forgetting something though). It's messy so brace yourself....

Code:
apt-get source libmozjs-dev

This will download the xulrunner source package to the current directory.
cd into the xulrunner-... directory
Code:
dpkg-buildpackage

wait until js/src/jsautocfg.h is created
Don't use the packages that dpkg-buildpackage creates --- I got a segfault when I used them. In fact don't wait for dpkg-buildpackage to finish as it takes forever.
Copy the newly created jsautocfg.h to deps/Cross-platform-deps/SpiderMonkey/js/src in the oolite-linux/trunk directory

Build deps/Cross-platform-deps/SpiderMonkey/js/src/fdlibm. Use deps/Cross-platform-deps/SpiderMonkey/js/src/fdlibm/Makefile.ref as the makefile

Modify deps/Cross-platform-deps/SpiderMonkey/js/src/Makefile.ref by adding the following line near the start of the file...
Code:
DEFINES += -DJS_C_STRINGS_ARE_UTF8 -UMOZILLA_1_8_BRANCH

Build deps/Cross-platform-deps/SpiderMonkey/js/src the using modified Makefile.ref for your makefile.

If libjs.so is present when you compile oolite it seems to link to that instead of libjs.a which is not what you want, so do...
Code:
mv deps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ/libjs.so deps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ/oldlibjs.so


Now modify GNUmakefile in the oolite trunk directory...
Change the line defining ADDITIONAL_INCLUDE_DIRS to:
Code:
ADDITIONAL_INCLUDE_DIRS = -Ideps/Cross-platform-deps/SpiderMonkey/js/src -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug

and change the line defining oolite_LIB_DIRS to:
Code:
oolite_LIB_DIRS += -Ldeps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -L/usr/X11R6/lib/


Make oolite with...
Code:
. /usr/lib/GNUstep/System/Tools/GNUstep.sh; make

And finally...
Code:
oolite.app/oolite


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 5:56 am 
Offline
Above Average
Above Average
User avatar

Joined: Sun Jun 24, 2007 7:29 pm
Posts: 31
Wow-- what a first post. I can confirm it works. Welcome aboard!

If you want the .debs a dpkg-buildpackage will also work instead of directly playing with gnustep-make. Also, for anybody who wants to follow the above: make -f ./Makefile.ref is your friend.

edit: in case you don't want to go through the hassle to build js/src/jsautocfg.h the file is:

Code:
#ifndef js_cpucfg___
#define js_cpucfg___

/* AUTOMATICALLY GENERATED - DO NOT EDIT */

#define IS_LITTLE_ENDIAN 1
#undef  IS_BIG_ENDIAN

#define JS_BYTES_PER_BYTE   1L
#define JS_BYTES_PER_SHORT  2L
#define JS_BYTES_PER_INT    4L
#define JS_BYTES_PER_INT64  8L
#define JS_BYTES_PER_LONG   4L
#define JS_BYTES_PER_FLOAT  4L
#define JS_BYTES_PER_DOUBLE 8L
#define JS_BYTES_PER_WORD   4L
#define JS_BYTES_PER_DWORD  8L

#define JS_BITS_PER_BYTE    8L
#define JS_BITS_PER_SHORT   16L
#define JS_BITS_PER_INT     32L
#define JS_BITS_PER_INT64   64L
#define JS_BITS_PER_LONG    32L
#define JS_BITS_PER_FLOAT   32L
#define JS_BITS_PER_DOUBLE  64L
#define JS_BITS_PER_WORD    32L

#define JS_BITS_PER_BYTE_LOG2   3L
#define JS_BITS_PER_SHORT_LOG2  4L
#define JS_BITS_PER_INT_LOG2    5L
#define JS_BITS_PER_INT64_LOG2  6L
#define JS_BITS_PER_LONG_LOG2   5L
#define JS_BITS_PER_FLOAT_LOG2  5L
#define JS_BITS_PER_DOUBLE_LOG2 6L
#define JS_BITS_PER_WORD_LOG2   5L

#define JS_ALIGN_OF_SHORT   2L
#define JS_ALIGN_OF_INT     4L
#define JS_ALIGN_OF_LONG    4L
#define JS_ALIGN_OF_INT64   4L
#define JS_ALIGN_OF_FLOAT   4L
#define JS_ALIGN_OF_DOUBLE  4L
#define JS_ALIGN_OF_POINTER 4L
#define JS_ALIGN_OF_WORD    4L

#define JS_BYTES_PER_WORD_LOG2   2L
#define JS_BYTES_PER_DWORD_LOG2  3L
#define JS_WORDS_PER_DWORD_LOG2  1L

#define JS_STACK_GROWTH_DIRECTION (-1)

#endif /* js_cpucfg___ */


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 9:13 am 
Offline
Mostly Harmless
Mostly Harmless

Joined: Sun Oct 14, 2007 12:47 pm
Posts: 3
Location: Ireland
Thanks --- glad to be aboard.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 11:02 am 
Offline
Grand Admiral Emeritus
Grand Admiral Emeritus
User avatar

Joined: Sat Apr 02, 2005 2:43 pm
Posts: 6653
Location: Sweden
Shade wrote:
edit: in case you don't want to go through the hassle to build js/src/jsautocfg.h the file is:

…unless of course you’re some sort of oddball using a different processor architecture. ;-)

_________________
E-mail: jens@oolite.org
Twitter: Oolite
Wish lists: computery, othery


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 3:03 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Sun Dec 03, 2006 9:07 pm
Posts: 341
Can't wait to get home to try this. :D

Question: Are debs produced this way portable between machines?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 7:18 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Sun Dec 03, 2006 9:07 pm
Posts: 341
It Worked. :D :D :D

Thanks Whisht.

I have placed the files on ftp://cloud9.dyndns.tv/Oolite in case they are of any use to other people.

If you use them please let me know whether they work for you.

The ftp server is usually up between 0630 and 2330 CET. Download speeds are limited to 256k (by the ISP, not me)
Log in as anonymous with your email addy as password.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 8:29 pm 
Offline
Mostly Harmless
Mostly Harmless

Joined: Sun Oct 14, 2007 12:47 pm
Posts: 3
Location: Ireland
Quote:
Question: Are debs produced this way portable between machines?

I don't know for certain, but if the same jsautocfg.h works for the same processor architecture, binary debs should be okay.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 15, 2007 8:48 pm 
Offline
Grand Admiral Emeritus
Grand Admiral Emeritus
User avatar

Joined: Sat Apr 02, 2005 2:43 pm
Posts: 6653
Location: Sweden
Issues other than processor architecture could potentially change the values in jsautocfg.h. For instance, a different ABI could have different stack order or data type sizes. Still, I would expect the posted version to work for all 32-bit x86 Linuxes and probably BSDs.

_________________
E-mail: jens@oolite.org
Twitter: Oolite
Wish lists: computery, othery


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 17, 2008 8:34 am 
Offline
Above Average
Above Average
User avatar

Joined: Wed Jan 16, 2008 10:44 am
Posts: 23
Location: Mooooooon
here's my jsautocfg.h, for 64-bit Ubuntu 7.10 on a PC:

Quote:
#ifndef js_cpucfg___
#define js_cpucfg___

/* AUTOMATICALLY GENERATED - DO NOT EDIT */

#define IS_LITTLE_ENDIAN 1
#undef IS_BIG_ENDIAN

#define JS_BYTES_PER_BYTE 1L
#define JS_BYTES_PER_SHORT 2L
#define JS_BYTES_PER_INT 4L
#define JS_BYTES_PER_INT64 8L
#define JS_BYTES_PER_LONG 8L
#define JS_BYTES_PER_FLOAT 4L
#define JS_BYTES_PER_DOUBLE 8L
#define JS_BYTES_PER_WORD 8L
#define JS_BYTES_PER_DWORD 8L

#define JS_BITS_PER_BYTE 8L
#define JS_BITS_PER_SHORT 16L
#define JS_BITS_PER_INT 32L
#define JS_BITS_PER_INT64 64L
#define JS_BITS_PER_LONG 64L
#define JS_BITS_PER_FLOAT 32L
#define JS_BITS_PER_DOUBLE 64L
#define JS_BITS_PER_WORD 64L

#define JS_BITS_PER_BYTE_LOG2 3L
#define JS_BITS_PER_SHORT_LOG2 4L
#define JS_BITS_PER_INT_LOG2 5L
#define JS_BITS_PER_INT64_LOG2 6L
#define JS_BITS_PER_LONG_LOG2 6L
#define JS_BITS_PER_FLOAT_LOG2 5L
#define JS_BITS_PER_DOUBLE_LOG2 6L
#define JS_BITS_PER_WORD_LOG2 6L

#define JS_ALIGN_OF_SHORT 2L
#define JS_ALIGN_OF_INT 4L
#define JS_ALIGN_OF_LONG 8L
#define JS_ALIGN_OF_INT64 8L
#define JS_ALIGN_OF_FLOAT 4L
#define JS_ALIGN_OF_DOUBLE 8L
#define JS_ALIGN_OF_POINTER 8L
#define JS_ALIGN_OF_WORD 8L

#define JS_BYTES_PER_WORD_LOG2 3L
#define JS_BYTES_PER_DWORD_LOG2 3L
#define JS_WORDS_PER_DWORD_LOG2 0L

#define JS_STACK_GROWTH_DIRECTION (-1)

#endif /* js_cpucfg___ */


that might save someone a few valuable seconds, maybe (though it was pretty easy to generate)


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 03, 2008 10:38 pm 
Offline
Grand Admiral Emeritus
Grand Admiral Emeritus
User avatar

Joined: Sat Apr 02, 2005 2:43 pm
Posts: 6653
Location: Sweden
Just a note: to build Oolite under Ubuntu 8.04, I also needed to add the following to my ~/.bashrc:
Code:
export GNUSTEP_MAKEFILES=/usr/share/GNUstep/Makefiles

It seems that this ought to be set up by installing the gnustep-make package, but it isn’t.

_________________
E-mail: jens@oolite.org
Twitter: Oolite
Wish lists: computery, othery


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group