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:

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.

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...!

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.

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?

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.

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!