Thread: [Ndiswrapper-general] problems with 2.6.0
Status: Beta
Brought to you by:
pgiri
From: Nathaniel D. <da...@ga...> - 2003-12-20 18:10:58
|
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 symbols: __floatsidf __fixunsdfsi __divdf3 __muldf3 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? Thanks, Nathaniel |
From: Nathaniel D. <da...@ga...> - 2003-12-20 22:01:47
|
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 default: $(OBJS) $(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 > symbols: > > __floatsidf > __fixunsdfsi > __divdf3 > __muldf3 > > 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? > > Thanks, > > Nathaniel > > > > ------------------------------------------------------- > 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 > Ndi...@li... > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general > |
From: Giridhar P. <gi...@lm...> - 2003-12-20 22:08:11
|
A correction: default: $(OBJS) $(CC) -Xlinker -r -Xlinker -static -o $(MODULE) $(OBJS) -lgcc should actually be default: $(OBJS) $(CC) -nodefaultlibs -static -static-libgcc -nostartfiles -Xlinker -r -o $(MODULE) $(OBJS) -lgcc This should work for 2.4 kernels; I don't know about 2.6 kernels though. If you know what is the equivalent way of doing it for 2.6 kernels, please let me know. I need 64 bit arithmetic for link quality code that I am going to add later. So I need to link libgcc.a. Giri. |