Doug Rabson wrote: > On Tue, 19 Jan 1999, Julian Elischer wrote: > > > > > If I load a module A > > then try load a module B that requires a function in A > > it fails because it cannot find the symbol.. > > is this a known problem? > > > > (A real bummer if so) > > The module B needs to have A as a dependancy. Use KMODDEPS to do this. > Something like this should work in the Makefile: > > KMOD= modB > SRCS= ... > KMODDEPS= modA > KLDMOD=t > NOMAN=t > .include <bsd.kmod.mk> > > The linker will only resolve symbols against the files in the dependancy > list (and the kernel).
I've been thinking that this could be improved. Yes, following the dependency list first for resolving symbols is right, I think there should be a fallback global search. Specific example (which is probably going to change today, but it's a good example): - wd.c has got hooks for the ATAPI code. - The ATAPI code can be build either statically or as a module. - ATAPI clients (acd, wfd, wst etc) therefore depend either on the kernel or the atapi module. If the atapi module was statically configured, and the acd driver depended on the atapi file, it would eventually fail due to conflicts. - However, if the acd driver didn't depend on atapi (the file), then a kernel compiled without it would be unable to load acd.ko regardless of whether atapi.ko had been previously loaded, because acd.ko won't see the symbold in atapi.ko. Does this description of the problem make sense? I think the symbol resolution should do a global search once the dependency list is exhausted. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
