MySQL on Maemo

I recently tried to build mysql packages to be able to access the client libs from libgda(mm) on maemo bora. I figured out how to build them on SDK_X86 by cutting down depencies as much as possible but failed to build them on SDK_ARMEL because of this internal compiler error:


if arm-linux-gnueabi-g++ -DHAVE_CONFIG_H -DNDEBUG -I. -I. -I../../../../.. -I. -I../../../../../include -I../../../../../ndb/include -I../../../../../ndb/src/kernel/vm -I../../../../../ndb/src/kernel/error -I../../../../../ndb/src/kernel -I../../../../../ndb/include/kernel -I../../../../../ndb/include/transporter -I../../../../../ndb/include/debugger -I../../../../../ndb/include/mgmapi -I../../../../../ndb/include/mgmcommon -I../../../../../ndb/include/ndbapi -I../../../../../ndb/include/util -I../../../../../ndb/include/portlib -I../../../../../ndb/include/logger -O3 -DDBUG_OFF -fno-implicit-templates -fno-exceptions -fno-rtti -MT Cmvmi.o -MD -MP -MF ".deps/Cmvmi.Tpo" -c -o Cmvmi.o Cmvmi.cpp; \
then mv -f ".deps/Cmvmi.Tpo" ".deps/Cmvmi.Po"; else rm -f ".deps/Cmvmi.Tpo"; exit 1; fi
Cmvmi.cpp: In member function `void Cmvmi::execTESTSIG(Signal*)':
Cmvmi.cpp:1463: internal compiler error: in verify_local_live_at_start, at flow.c:546
Please submit a full bug report,
with preprocessed source if appropriate.
Send email to arm-gnu@codesourcery.com for instructions.

It’s not a major issue as I was able to build PostgreSQL packages and one database is enough in the moment but if someone has an idea what I could do about it I would be glad to hear.

In the meantime a have put up a small howto for installing an SDK for C++ development on the Nokia N800.

Bad ideas!

It was a real bad idea to fix the anjuta .desktop file recently to allow proper bugs reports in bugzilla. People just file to many crash bugs now…

Linus’ metacity patches

So, I just read Christan Schaller’s blog about the patches Linux Torvalds submitted to metacity and control center.

As that is not really mentioned anywhere (and I had to search various mailing list archives) here is the original mail, so anyone can get an idea of what these patches do and why someone would want to have this options. I don’t know if this patches a good, useful, whatever.

I am just a bit upset about the way this communication happened between people from GNOME and some contributor. I say some contributor here because we should not make any difference between people willing to help us. Linus is like anyone else and if he sent patches to the wrong mailing list than we can politely tell him. Of course, Linus might not have ever been fair to the GNOME community but nevertheless nobody should treat him differently than anybody else therefore (see Code of Conduct).

GNOME rocks! Let’s make it even better!

Anjuta 2.1.1

So not even one month after the last release, anjuta 2.1.1 hits the road. We have fixed a lot of annoying bugs so I hope you will enjoy this release. We will continue to concentrate on bug-fixing but will probably create some interesting branches in the meantime to get even more cool feature in. Grab it from Anjuta.org!

As Murray already posted we at Openismus are still working on finishing libgdamm and libgnomedbmm. We did not expect that we would have to work so much on the C sources (see my previous post) but I hope we can finish them soon.

Use construct properties

This is a comment for all people writing GObject-style libraries that may have to be wrapped for other programming languages (C++, etc). And as you only write cool libraries which will be that useful that they will one day be wrapped, this applies to all your libraries.

Construct properties
Add a property for every parameter of your _new method. These parameters can be restricted to G_PARAM_WRITABLE|G_PARAM_CONSTRUCT_ONLY if it is useless to set them after initialisation. The actual setting is done by overriding the set_property method of GObject. You can also ref/unref you parameters if necessary there.

The *_new method
The new method should just consist of one call to g_object_new(MY_TYPE, “foo”, foo, “bar”, bar, …, NULL). NEVER add anything else to this method!

The _init method
Here you can do as much initialisation work as you like. This method is called by the GObject system and thus will be accessed from all language bindings.

Why?
When wrapping a library it is lots of work and takes lots of time to convert every parameter to a construction property and to move all other initialisation code from _new to _init. Besides it is clean and everybody will start loving you…(and you would have saved me at least two hours today!)