Re: 2.4.20; unresolved symbols

On Thu, 11 Sep 2003, Avin Sigurani wrote:

> --- Donald Becker <[email protected]> wrote:
> > On Sat, 6 Sep 2003, Avin Sigurani wrote:

> > > After compilation, the pci-scan module seems to
> > load
> > > just fine, but the rtl8139 module gives the
> > following
> > > errors when I attempt to load the module:
> /lib/modules/2.4.20-lunar-grsec-xfs-int-rc3.1/kernel/drivers/net/rtl8139.o:
> > > unresolved symbol softnet_data_Rcc6ef497

> I have tried to compile the modules with 2.4.21, and a
> patched distribution that, as with many distributions,
> is recommended by the distro.  I get unresolved
> symbols under all circumstances.

Unresolved symbols problems, such as the message above, occur when you
are trying to install a module built for the wrong kernel.  You must
compile the module using the header files for the exact kernel you are
running.

>  I assume when you
> ask if I have recompiled my kernel, you mean to ask if
> the kernel in the current source tree matches the
> running kernel, in which case, the answer is yes.

Not a kernel with the same version number, but a kernel with exactly the
same source code, configuration options, and compiler.

If you have recompiled the kernel and are seeing this problem, you have
not put the kernel header files in a standard place.  A typical problem
is recompiling the kernel over top of a previous compile, which discards
the generated header file information.  At that point it is difficult to
regenerate header files that will allow you to build modules for the
previous kernel.

Please note that I'm not defending the Linux kernel module system.  It
has caused much user grief over the years.  It was badly designed and
the frequent changes over the years have only created version
incompatibility without fixing the problems.  There were simple things
that could have been done to mitigate the problem

> At first, I had not used the makefile, compiling the
> modules by hand, but now I have used the tarball that
> comes with the makefile, and it seems to make no
> difference.  The kernel I attempted to compile against
> last time had patches for the xfs file system, the
> grsecurity patch, international cryptography, and a
> few minor patches made by the distribution team. 
> However, a fresh, pure kernel source tree still gives:
> 
> cb_shim.o: unresolved symbol unregister_hotswap_hook
> cb_shim.o: unresolved symbol register_hotswap_hook
> cb_shim.o: unresolved symbol unregister_driver
> cb_shim.o: unresolved symbol register_driver

This is "normal", even if it appears broken.  The cb_shim.o module is
only needed if the external PCMCIA support is used.  When they pulled
part of the PCMCIA code into the kernel, they didn't provide a way for
an external compile system to figure out which interface to use.  So I
must build the interface module unconditionally.

> pci-skeleton.o: init_module: No such device

This looks good -- the example driver module loaded and correctly
complained about not finding its device.  

> I believe I need only pci-scan.o, cb_shim.o and
> rtl8139.o for the D-link DFE690TXD.  Is this correct?

You likely only need pci-scan.o and rtl8139.o

> I don't know much about the kernel code, writing
> drivers, etc., and so I don't really know where to
> begin here,  but I am willing to do some work, look
> throught he code, etc.  if it will help.  Thank you
> for your time.

That's a much better attitude than a few interactions that I've had
recently: "I broke this and I demand that you fix it".  Earlier this
week I had was flamed with "Take me off the mailing list by hand or I'll
report you as a spammer."  Every time I would send instructions and
explain why I don't do unverified removes I would get a harsher flame...

-- 
Donald Becker				[email protected]
Scyld Computing Corporation		http://www.scyld.com
914 Bay Ridge Road, Suite 220		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993