So the problem here is that as of 2.6.0 test7, the kernel has included
-msoft-float in the build options for x86, which causes floating point
arithmetic to generate library calls that aren't linked in. As far as I
can tell from the discussion on linux-kernel, this is actually done to
discourage using floating point arithmetic in the kernel (which is
evidently not supposed to be allowed), by causing the error messages that
I have been experiencing.
There would seem to be 3 solutions:
1) Rewrite wrapper.c to avoid FP. It is not obvious to me how to do this
for one of the uses (involving fractional powers of 10 for computing
transmitter power), though the otehr (involving channel frequencies) seems
easy enough to do with ints.
2) statically link in the library functions. Giridhar Pemmasani says this
can be done by replacing the default: make rule with
$(CC) -Xlinker -r -Xlinker -static -o $(MODULE) $(OBJS) -lgcc
I haven't tried this yet.
3) remove -msoft-float from /lib/modules/2.6.0/build/arch/i386/Makefile
for the purpose of building the module. This works for me, but it is
kindof a hack.
Anyway, something should probably be done about this because I think it
will face everybody who tries to use it with 2.6.0 release.
On Sat, 20 Dec 2003, Nathaniel Daw wrote:
> I have been using ndiswrapper successfully with a 2.4 kernel and have
> recently tried to update to 2.6.0 (the fedora/redhat/rawhide build).
> One bug becomes apparent in the latest CVS: In order to compile the
> module, I had to rearrange the includes in loader.c. In particular, the
> #define of "packed" in ndis.h causes some uses of __attribute((packed)) in
> some of the 2.6 system include files to misparse. So I moved ndis.h to
> last to get it to compile. I think this change should be comitted as it
> seems otherwise harmless. (Alternatively, the iffy redefinition of packed
> in ndis.h should be removed or renamed.)
> Anyway, despite this I can't get the module to load because of unknown
> I think these are related to floating point arithmetic in wrapper.c and
> to my use of gcc 3.3 (about which I have no choice since the vendor
> compiled the kernel using that). But I haven't the slightest idea how to
> solve it. Does anyone have any advice?
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> Ndiswrapper-general mailing list