Problems porting L4Linux 2.4 module to 2.6

[Derick Swanepoel]

On 20/09/05, Adam Lackorzynski <adam at os.inf.tu-dresden.de> wrote:
> In 2.6 they're writing the EXPORT_SYMBOLS directly under the functions
> and not in a single file anymore. I've added a few to the bottom of the
> main.c file but for sure not all the needed ones. We haven't been
> playing around with l4 related modules lately so this is why those
> symbols are missing. Just add the ones you need and send the list over,
> I'll add them.

Thanks Adam. I added the following to arch/l4/kernel/main.c:

EXPORT_SYMBOL(kmalloc);
EXPORT_SYMBOL(l4_sleep);
EXPORT_SYMBOL(l4lx_thread_create);
EXPORT_SYMBOL(l4lx_thread_shutdown);
EXPORT_SYMBOL(l4rm_detach);
EXPORT_SYMBOL(l4rm_do_attach);

#include <l4/names/libnames.h>
EXPORT_SYMBOL(names_waitfor_name);

I also needed l4env_err_ipcstrings, but it isn't defined anywhere so I
added it as a dummy function to my module (as in
pkg/overlay_wm/examples/xf86screen/dummy.c). I hope this is correct.

> > Secondly, I get more unresolved symbols if the objects that are linked
> > are specified at the end of the command line instead of the beginning
> > (linking succeeds in both cases, however). The kernel build system
> > puts the objects at the end while the DROPS build system puts them at
> > the beginning. Does anyone have an idea why two otherwise equivalent
> > linking commands would cause such different behaviour depending on the
> > position of the object arguments? Here are the two command lines (the
> > paths are slightly different because the kernel build system always
> > outputs to the source directory:
> 
> I guess that's because of the way ld works, it only processes the list
> of arguments once (if not told otherwise) and depending on the order of
> the objects/libs given different unresolved symbols may occur.

I know that one can tell ld to repeatedly search archives until no new
undefined symbols are created (using --start-group and --end-group),
but this didn't help. Is there another way? For now I've resorted to
hacking the kernel build system to place the objects at the beginning,
but I know this is not the right way.

Thanks,
Derick