Problems porting L4Linux 2.4 module to 2.6
adam at os.inf.tu-dresden.de
Thu Sep 22 00:22:00 CEST 2005
On Wed Sep 21, 2005 at 11:55:04 +0200, Derick Swanepoel wrote:
> 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:
> #include <l4/names/libnames.h>
> 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.
I've added those except kmalloc. How does it come that there's a kmalloc
symbol? kmalloc is a static inline function in slab.h so there should
not be an unresolved symbol, no?
> > > 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.
Well but it works nevertheless? Generally I'd recommend to use the Linux
build system to build modules, should be easy with the "make -C ...
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers