On Wed Sep 21, 2005 at 11:55:04 +0200, Derick Swanepoel wrote:
On 20/09/05, Adam Lackorzynski adam@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.
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 ... M=..." syntax.
Adam