Oolite Bulletins

I'm almost there I'm trying to run a slight segmentation fault in SDL to ground then I'll get it to winston to host. Currently I have two seperate packages for FreeBSD 5 and FreeBSD 6. The only difference between the two builds is the links to the core system libraries. Is it worth me buiding both? FreeBSD 6 has /usr/ports/misc/compat5x which enables 5.X binary compatability and you currently need it to get NVidia openGL acceleration in X (Which is about the only decent OpenGL acceleration in FreeBSD at the moment).

What do people think?

Ah, good news all around! :-)
I'd say just stick to a 5.x release for the time being, I don't really see any point in doing a separate 6 release at this time, the compat5x is usually installed anyway if you've been upgrading and it's not that big really...

Will we be seeing it in ports soon then?

Currently I'm just emulating what the stand alone Linux package by Winston does. I have no intentions of integrating this into the FreeBSD ports tree for primarily time and responsibility reasons. I can provide installation notes and diffs for any changes if you are volunteering

Spooky wrote:

I can provide installation notes and diffs for any changes if you are volunteering

In that case allow me to also call upon the "time and responsibility reasons" clause for the time being as well.

Ahhh, the wonders of GNUstep... I was wrong to point the finger at SDL it was merely a ruse. After a long and productive period with gdb I can confirm that GNUstep is having a serious falling out with libpthread during __objc__init_threadsystem(). Yay!

Once again this may inhibit the timescales on my getting this finished...

Sorted

There are some serious issue with threading libraries in FreeBSD. A quick change to the GNUmakefile to switch to -pthread instead of -lpthread and it looks like we're laughing. I'm gonna run it through gdb tomorrow morning just to make sure everything is tickeyboo and then it's onto a FreeBSD 5.X build.

Spooky wrote:

Sorted

Great!

(That's the Evil Genius Grin(TM), I presume?)


(Edit:) Next Step (pun intended) : we gotta get Oolite to run on a toaster....

(That's the Evil Genius Grin(TM), I presume?)

Yeah why not... if it makes you happy

(That's the Evil Genius Grin(TM), I presume?)

You jest, but I'm working on a NetBSD 3.0 build too... so if anyone has a GL equiped toaster they could lend me I'll give it bash

I've got the 5.X package done and tested it on a few machines. It seems to exhibit the same requirement for a link between Oolite/oolite-deps/GNUsetp and /usr/GNUstep as the IRIX build did. Again I've solved this with a check and link in the installer. This has to be something I'm doing as I am now one of the only two common denominators in the equation... the other being GNUstep itself.

Unfortunately it seems that I wont be able to opt for the lazy cop-out of only providing a 5.X tarball.

NSProcessInfo: kinfo_proc size missmatch (expected 648, got 748)
Error: libkvm cannot find the current process
Abort trap (core dumped)

I guess I'm gonna have to build a bit of a compile farm to produce all these tarballs with any kind of regularity.

Sorry for the slight change in direction, here, but it's very simple to get the 1.62-3 version to build on FBSD-6, using the skeleton in ports - 3 changes required in total.
New distinfo file, obviously; 1 line modification to Makefile (PREFIX); and a 1 line patch to single source file (SDL/SDL.h).

When I get chance, I'll mail the port maintainer with the info.

I'm not yet 100% sure, though, that all of the memory issues are fully resolved - may be due to AddOns, but I continue to investigate.

celkins wrote:

I'm not yet 100% sure, though, that all of the memory issues are fully resolved - may be due to AddOns, but I continue to investigate.

You've probably already read about the outdated AI plists in the linux build that were the likely culprits, hence the 1.62-3 build. I noticed yesterday that Giles has found a problem within the AI code, that those plists may have triggered. If so, try removing any OXPs with bundled AI code and see what happens.

Giles' post regarding the issue may be found here.

Celkins:

A few observations of my time doing prebuilds on *BSD.

I stayed away from the ports version of SDL due to the changes in location and sdl-config renaming. It doesn't really affect anything but I find it a pain in the arse. A single filesystem structure makes it simpler to do regular builds on the build farm I've constructed.

I also found the amount of dependancies for the port totally unacceptable. There's far too much baggage there, thanks in part to SDL and the GNUstep port dependancies... I guess I'm just *REALLY* anal about that stuff

Indeed getting it to build on FreeBSD is easy, even without the ports skeleton you only need a few changes to the GNUmakefile and you're away. You might want to check the threading library used by GNUstep and Oolite though. -lpthread caused indescriminate segfaults on both FreeBSD 5 and 6 on the 3 machines I did burn-ins on.

If people like I can provide instructions for compiling the whole kit and caboodle yourself from scratch?

I have problems with OXP and oolite 1.72 on FreeBSD.
If I use RandomHits for example oolite will crash randomly with strange malloc assert.

Changing thread library did not help, so any hint what to modify would be very nice.

Well, I found solution for the random crash problem. It was DRI Mesa bug on intel cards. Installing latest RC fixed it.