Re: 2.4.20; unresolved symbols

--- Donald Becker <[email protected]> wrote:
> On Thu, 11 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.
> > 
> > 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".  

As I have said, I am in fact compiling against the
runing kernel.  Just in case, the first time you
suggested that this was the problem, I recompiled the
various kernels I was using.  Before I compile the
modules, I reboot into the kernel I want and change
the symbolic link "linux" in /usr/src to point to the
source tree of the running kernel.  

So there is absolutely no doubt in my mind that I have
compiled the modules against the correct kernel
versions.  Unless there is another symbolic link I
don't know about, it sould have used the correct
kernel headers, and even if there is, at least one of
the compilations should have worked as it has to point
to the correct kernel source tree at least one time.  

So, the problem is something else.  Perhaps it has to
do with the libraries I am using? or the compiler?  Or
something.  I don't really know.  But I have been
using linux for some time and the distribution I have
now is a still unstable source based distribution
which relies on bash scripts to download and compile
source.  I have contributed several such scripts to
the distribution, so I should know in general what I
am doing.  I have not written any drivers, don't use
system calls much, or anything like that, but unless
there is something drastic I have overlooked in my
linux/unix education, I don't see how it could be
related to linking against the wrong source.  

I have tried to compile and load these modules over
and over again, looked around on the web, etc.  and
still they do not work, always complaining about
unresolved symbols in various combinations and
permutations.  The first time I got the modules to
work (in Redhat linux) i had to modify the source
code, as it refused to compile, though I don't
remember precisely what I did.  Since I upgraded my
debian distro, later switching to my current distro, I
have not had funcitional drivers for this card, which
is a slight problem for me, as the card I have now, a
xircom, is about to go kaput.  If there is any
information you wish me tobtain somehow, I'll be glad
to search for it, and would really appreciate it if
you could help me get this card working again. Thanks.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com