Oolite & Lucid (Ubuntu 10.04)

[tinker]

So is there a way to force the build to use the earlier version in the trunk tree? Or is it better to find an update >=1.21.1 ?

[Micha]

In the current Oolite trunk, "make -f Makefile release" will use the dependencies in the source tree rather than the system libraries.
[EDIT]This has been reverted again. Building using the included dependencies is for packagers-only anyway and not easily supported on a stock distribution.[/EDIT]

I'm not 100% sure how to then setup your system to run the resulting binary. Getafix is your expert there. Probably some LD_LIBRARY_PATH magic.

Alternatively download & compile GNUstep trunk and install it in your system. But you'll end up with non-standard binaries and any bugs or issues you encounter may or may not be due to Oolite. They could be due to that version of GNUstep and since you're the only one using it, they won't be known.

[Getafix]

As I see it the following options exist:

Without changing your system's gnustep:
1. If you just want to play, download and install the 1.73.4 auto-package
Make sure to uninstall any installed oolite first!

2. If you want the bleeding edge you can install oolite-trunk the nightly auto-package.
It can be installed in parallel with normal oolite (option 1) but they share saves, logs and add-ons

Change your system's gnustep:
3. Compile and install gnustep 1.18 (stable) and oolite source
a. Download, compile and install gnustep-base 1.18
deps: gnustep-make, libffi-dev (libffi4-dev for ubuntu less than lucy), libxml2-dev

Code: Select all

$ wget http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-base-1.18.0.tar.gz
$ tar xzvf gnustep-base-1.18.0.tar.gz
$ cd gnustep-base-1.18.0
$ ./configure --prefix=/usr/share/GNUstep --disable-xslt --disable-tls
$ make
$ sudo bash
password:
# make install
# exit
$ exit

b. Rebuild your oolite source

Code: Select all

$ make -f Makefile clean
$ make -f Makefile distro-release

[tinker]

Thanks fro the help guys.

I was already using the 1.73.4 auto-package as that was the only one that ran out of the box. I have now added the oolite-trunk nightly auto-package so I can do some new oxp testing and that is working OK, is there a 64bit nightly auto-package?

@Micha

In the current Oolite trunk, "make -f Makefile release" will use the dependencies in the source tree rather than the system libraries.

This doe not work, the build fails before I even get to the problem of running it.

[Micha]

There's patched gnustep libraries for Ubuntu Lucid and Maverick. They can be accessed at a PPA here:
https://launchpad.net/~3-launchpad-mich ... rchive/ppa

The related bug is being processed by Ubuntu. It may take a while before it trickles into the proper distro archives, if at all.

[caracal]

I have now added the oolite-trunk nightly auto-package so I can do some new oxp testing and that is working OK, is there a 64bit nightly auto-package?

I asked the same thing in another thread but haven't gotten a reply yet. But the 32-bit nightly autopackage worked okay for you on a 64-bit system? I want to try the newest stuff, and I understand the risks, but don't want to get to the point where I can't play oolite at all!

[Getafix]

In the current Oolite trunk, "make -f Makefile release" will use the dependencies in the source tree rather than the system libraries.

This doe not work, the build fails before I even get to the problem of running it.

Currently the only build option for users, who do not want to have oolite deps built and installed on their system, is "distro-release".
This option is also the only one to be used when a deb package is to be build.

All other options are used only for oolite development and maintenance in order to have oolite packaged with a steady set of libraries.

[tinker]

I have now added the oolite-trunk nightly auto-package so I can do some new oxp testing and that is working OK, is there a 64bit nightly auto-package?

I asked the same thing in another thread but haven't gotten a reply yet. But the 32-bit nightly autopackage worked okay for you on a 64-bit system? I want to try the newest stuff, and I understand the risks, but don't want to get to the point where I can't play oolite at all!

Yes the 32 bit nightly auto-package works OK on a 64 bit system, but it is bleeding edge and liable to fall over sometimes. As it is a separate install it should not affect your existing build but they do share addons, logs and save games. I use a separate save game for trunk play just to be safe.

[caracal]

Yes the 32 bit nightly auto-package works OK on a 64 bit system...

Thanks, very good to know!

...but it is bleeding edge and liable to fall over sometimes. As it is a separate install it should not affect your existing build but they do share addons, logs and save games. I use a separate save game for trunk play just to be safe.

Heh, thanks for the warnings. I do have some understanding of how software works, or doesn't work ... been writing it long enough.

I'm curious what you mean by "separate install", though. That's the second or third time I've seen somebody say that. When I installed the 1.73.4 autopackage (the stock Debian version being 1.65, yow!), it put itself into ~/.local. Are you saying the nightly puts itself somewhere else? Or does it append version numbers to its pathnames or summat? Just curious. I guess I could try it in a VM or something.

Anyway, thanks for the info. I've just about built up the tuit to give it a try!

[Kaks]

Are you saying the nightly puts itself somewhere else?

Yep! And you get a second menu shortcut, called oolite-trunk, next to the original shortcut.

[caracal]

Are you saying the nightly puts itself somewhere else?

Yep!

Okay, you guys convinced me to give it a try. And indeed it does put itself "somewhere else" ... into ~/.local/lib/Oolite-trunk instead of just .../Oolite. And the binary has "-trunk" appended too, which is very nice. Great job, guys!

Only my delight was short-lived:

Code: Select all

./oolite.app/oolite: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory

Erk. It looks like Oolite-trunk died with an error. When making an error
report, please copy + paste the log above into the report.

Probably because my /usr/lib/libGLU.so.1 is "ELF 64-bit LSB shared object, x86-64", which I bet the 32-bit executable doesn't care for. In fact, I get a whole bunch of libs "not found" when I do an ldd on the binary. Oh well!

And you get a second menu shortcut, called oolite-trunk, next to the original shortcut.

Yes indeed you do, very nice!

In poking around before taking the leap, I found something that I probably read months ago and just forgot, which explains why (1) there's no 64-bit nightly build, and (2) why the developers figured I was too much of a chowderhead to reply to when I asked about it:

Currently, a native 64-bit build isn't available as a binary download because none of the developers has an amd64 system. If you are capable of building Oolite-Linux from source and have a suitable machine, it would be greatly appreciated if you can volunteer to be the maintainer of the amd64 build.

I might be willing to discuss providing a 64-bit build. I've certainly built oolite from source before, back in the 1.72 days, though I used its built-in Debian stuff rather than autopackage. Even though Debian is still currently shipping the obviously-broken libgnustep 1.19, I don't have any packages that depend on it, so could use any version you guys wanted me to try. (And yes, I realize that the source comes with its own copy of 1.16, which is fine too.)

I'm not entirely sure I'm quite ready to become "the maintainer of the 64-bit build", though. Sounds so formal and responsibility-like. Maybe I should just grab the source, build it, and come back to talking once I have a working binary.

[caracal]

Maybe I should just grab the source, build it, and come back to talking once I have a working binary.

Well that was easy. Certainly easier than back in 2008!

Now, however, I think I'm running into the libgnustep issue. It's linked against Debian squeeze's native 1.19.3, which has been established as broken for oolite purposes. What I'm seeing is:

• The app comes up just fine,
• All errors in the log seemed to be related to those OXPs I have installed which need to be updated for 1.74+,
• The game seems to run fine, and everything works as expected (very pretty, I might add!), BUT
• All of my saved commanders with OXP ships (except one, oddly enough) show the dreaded spinning question mark.

Is that what I should expect with a bad libgnustep version? BTW, what I found odd about the one saved commander with an OXP ship that did work okay was that he has the same OXP ship as another commander who showed the question mark. But eh, with buggy libraries, any sort of anomaly isn't that remarkable.

Anyway, I'm certainly encouraged by how simple the build has become, and after I figure out what I want to do about the library issue, I may indeed volunteer to provide at least some 64-bit packages. I'll let you know.

[Thargoid]

The spinning ? part is quite probably linked to the space-eating issue (See here) making the save game ship ID key mismatch the OXP one.

[Getafix]

@caracal
If you are willing to install the stable gnustep-1.18 on your system,
I can provide you with instructions.

[Micha]

Now, however, I think I'm running into the libgnustep issue. It's linked against Debian squeeze's native 1.19.3, which has been established as broken for oolite purposes.

You can also try installing a fixed gnustep from here debs.oolite.org if you like. (Sorry, no specific version built for squeeze, but I think you can install most Ubuntu packages on Debian as well).

(Updated 2010.10.19)