Berkeley db and libstldb4 for s60

It turns out the problem I was having with bdb on s60/openc was that the default stack size is very small (by desktop standards). Adding EPOCSTACKSIZE 65536 to the mmp file of the test client made things work as one would expect when the sis file is installed on the device itself.

If your stack is too small then the application just magically goes away on the device and you are left wondering why. Not only that but if the function that smashes the stack with auto variables is tracked down you will have a function that, once entered, will have a corrupt stack right from the start. Functions like open(2) will not work properly because things are already on their way to the bit bucket. These sorts of things take a while to track down when you are used to stacks that adjust their size when they get full.

So, long and the short, stldb4 now works on s60/openc :)

I notice that there is also SDL for symbian which when taken together with the fact that evas has a backend engine for SDL makes edje/evas GUIs for desktop and s60 seem like a good choice. Being able to debug the look and feel of the app on a desktop using a window of device size and then just running the edje on the s60 to see if any special effects run fast enough.

Symbian and Open-C: A porting we shall go

Yay, I now have libsigc++, libferrisloki, libferrisstreams and stldb4 compiling and all but the last one actually useful on an Nokia E61. It makes a huge difference to the whole coding for embedded knowing that you have decent std iostreams and intrusive reference counted objects.

The stldb4 is a pain in though as it crashes in the test client. Its just so much fun that the remote debug stuff is work thousands of Euros, making on device testing just so easy for folks who dont have suitcases of cash laying around.

Looks like ye olde cout << "...1" << endl; on device debugging until I manage to move something like Enamel out of libferris onto the s60. Perhaps a port of syslog to symbian would help, atleast I'd be able to get network streamed log events.

Very few changes actually were required in libferrisstreams. Unfortunately the madvise() call was one of them. This gets used in ferrisstreams for memory mapped IO to tell the kernel of sequential IO access with MADV_SEQUENTIAL. This is probably more relevant to desktop and server machines than embedded anyway, seek times being so different between a flash disk and regular HDD.

All I need to do now is actually iron out why Berkeley db-4.x on symbian is deciding to do funny things for me and I'll have quite a nice little start making a nicer coding environment for s60.

Shame I'm too late for the little Open-C port a posix contest that was floating around.