I wish this week had been as fun as the previous one, which included RMLL meetings + some other (really nice) meetings. But it seems I'm now kinda out of luck or cursed, core system tools are now haunting me :-/

This week-end, it was splashy that was bothering me again. Since we are considering its inclusion in Mandriva Linux 2008.0, to replace the bootsplash kernel patch, I had to try it.

The version I packaged in Mandriva Cooker was not really functional (it segfaulted...), so I had to debug it. The initial segfault was quite easy to debug (after making splashy not fork at startup), a couple of checks about directfb initialization were missing (patch).

That was rather not a good sign, splashy really needs DirectFB to work. Looking further in the execution with gdb showed that dfb_system_lookup() failed to find a directfb "system". Actually, the direct_modules_explore_directory() does not even bother to look in the modules directories when statically build (i.e. when built with -DPIC, passed by libtool), which seems logical.

So, how does it works with static builds? Actually, each directfb system uses a macro in its source code to register the module at program initialization, using a constructor attribute, which allows to run functions before even entering main():

#define DFB_CORE_SYSTEM(shortname)                          \
__attribute__((constructor)) void directfb_##shortname();   \
void directfb_##shortname() {                               \
     direct_modules_register( &dfb_core_systems,            \
                              DFB_CORE_SYSTEM_ABI_VERSION,  \
                              #shortname, &system_funcs );  \
}

For this to work, splashy need to be linked with at least with one directfb system, which is not included in the main directfb static archive. So, to use fbdev, I've added --system=fbdev to the directfb-config call in the Makefile.

But, again, it's not that simple when linking with static archives, objects from an archive are not used if they don't resolve any symbol (mail on gcc-help). A trick is to force a symbol contained in an object to be resolved, by marking it unresolved using the -u option of the ld linker. In my case, I added -Wl,-udirectfb_fbdev in the Makefile to pick the fbdev directfb system at linking.

That's better, but splashy still does not work. It needs a few more systems to be initialized, and it was a pain to debug with gdb, because directfb does not build with -O0, and building with -O1 makes it a bit more difficult. Eventually, I found out that directfb required a few more modules to be started correctly, such as a keyboard one and a wm one. Adding -Wl,-udirectfb_keyboard and -Wl,-udirectfbwm_default made the trick (final patch).

And finally, it starts \o/

Now, we need to integrate splashy in our initscripts, which should just be a matter of calling splashy_update "progress <percent>". We also have to provide a solution to keep background in tty (like the bootsplash kernel patch provided). A small daemon using directfb could do the trick. Hopefully.