How to build Oolite source on Ubuntu

[zevans]

Hi all. Trying to build the nightly and since I last tried it Ubuntu has changed a lot, and so has Oolite, so I was expecting trouble... and I got it.

I ran

Code: Select all

git submodule update --init

to pull in SpiderMonkey but then I hit trouble trying to compile it. I had a look at Mozilla's own build guide. It seems it's pegged to autoconf2.13 (ie an old version) but fortunately Ubuntu has a specific package for that, so I installed it.

In the interests of troubleshooting I am running make directly in the

Code: Select all

oolite/deps/mozilla/js/src

directory.

Code: Select all

$ autoconf2.13
$ ./configure
$ make
[ ... lots of typedef warnings...]
jsapi.cpp: In function ‘JSIdArray* JS_Enumerate(JSContext*, JSObject*)’:
jsapi.cpp:3980:16: error: cannot convert ‘bool’ to ‘JSIdArray*’ in return
         return false;
                ^~~~~
config/rules.mk:1475: recipe for target 'jsapi.o' failed
make[1]: *** [jsapi.o] Error 1
make[1]: Leaving directory '/scratch/src/oolite/deps/mozilla/js/src'
config/rules.mk:753: recipe for target 'default' failed
make: *** [default] Error 2

Any ideas... ?

[Getafix]

Have you tried the following?

(2.2) Build Oolite
CD into the root of Oolite source (e.g. ~/Oolite-dev/trunk or ~/Oolite-dev/1.75.3)
and execute

Code: Select all

make -f Makefile release

(2.3) Run Oolite

Code: Select all

oolite.app/oolite

It should also build SpiderMonkey.

[zevans]

Aha - some lateral Googling and I've found a load of similar FTBFS problems in some other distros. I think something has been deprecated in the new version of gcc (6.3) so now I'll have to find the flag to tell it to back off a bit...!

[zevans]

Yes I tried that first and THEN narrowed the problem down to SpiderMonkey. Sorry, didn't make that clear. Looks like a gcc 6.3 v ancient SpiderMonkey thing.

[another_commander]

From this page: https://gcc.gnu.org/gcc-6/porting_to.html

Cannot convert 'bool' to 'T*'

The current C++ standard only allows integer literals to be used as null pointer constants, so other constants such as false and (1 - 1) cannot be used where a null pointer is desired. Code that fails to compile with this error should be changed to use nullptr, or 0, or NULL.

[zevans]

It is an issue with the bundled version of SpiderMonkey. For example see here:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=811665
So the Debian package includes the fix.

So I guess I need to try using the external package of 1.85, or see if there's a version that the Oolite devs could re-bundle without any other breaking changes. That assumes that the Debian fix above has made it back upstream into the wonderful world of Mozilla.

This is going to affect everyone on GCC 6 though surely, which is a much wider problem than Ubuntu specifically?

[another_commander]

We cannot rebundle a different Spidermonkey version without affecting the Windows port. The Spidermonkey we currently use has been configured to run on all three supported platforms and managing to build it on Windows has been a very demanding task. So demanding, that I would not want to ever have to repeat it.

What can be done though, is apply the fixes for these errors to our repository's version. Basically the fix for these kind of errors is to replace return false with return NULL, which we should be able to do if we have the full list of such occurences.

[zevans]

Thanks for the replies. After digging through the source a bit and looking at some old bug discussions around the web, I feel your pain! I was just reading the thread where you guys were discussing this very problem as justification for bundling a version. So I agree it's gonna stay bundled.

I tried a build against Zesty's libmozjs185-1.0 out of curiosity, and basic things like JS_DestroyScript have changed, so even if you didn't have the Windows constraint, an update would be major work. (I think I remember a realignment around 1.74 time turning into an express elevator to hell...)

Rather than clutter up this sticky thread with more discussion I'll start another one and we can come back here with the conclusions. Thanks!

[Getafix]

De-stickified as outdated.