FAQs on Building MADWiFI
I get 'No rule to make target /lib/modules/{kernel_version}/build/.config
/lib/modules/{kernel_version}/build should be a symlink to /usr/src/{kernel_version}. You’ll get this error if it isn’t. To correct the problem, first install your distro’s kernel sources (people with home rolled kernels don’t generally get this problem - for more or less obvious reasons), and then do:
# cd /lib/modules/{kernel_version}
# ln -s /usr/src/linux-{kernel_version} build
# and to check it worked:
# ls -al build
You should see something like this:
lrwxrwxrwx 1 root root 21 Sep 22 17:12 build -> /usr/src/linux-{kernel_version}
If you’ve just installed a RedHat? kernel package, have all of the correct symlinks, and it still won’t work, then it could be because you don’t have a built/configured kernel. To fix this problem cd into your kernel tree and build it as normal. [Note: previous driver incarnations did not require a built kernel tree, however recent versions (post Dec 2003) have used kbuild in the Makefile, which need to use some parts of the built kernel.] iwconfig reports: No wireless extensions.
You need to build a kernel with CONFIG_NET_RADIO and CONFIG_NET_WIRELESS enabled. Normally selecting the former in menuconfig automatically enables the latter too, but if you’re editing by hand, remember to set both, since its the WIRELESS bit that switches on /proc/wireless.
You can get the latest wireless extensions from: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/ although most recent kernels already have them.
According to Felipe Saint-Jean, you also need to ensure that your kernel is built with SMP (CONFIG_SMP) support off.
Jason Lewandowski also suggests restarting PCMCIA services, you may find this helps.
I get, 'Unresolved symbols in _IEEE(something)', help!
You must make sure that you build your kernel with CONFIG_MODVERSIONS=n, thanks to Joe Milbourn for (inadvertantly) testing this!
Also, Jon Bohlke points out that if you’ve patched the driver into your kernel source, you need your kernel to have IEEE.80211 in it’s config.
Why is the kernel source required to build Madwifi?
This answer is a mixture of mailing list discussion from Per Bjornsson and Greg Chesson.
Contrary to public myth, the full kernel source code is _not_ required in order to build the MADWIFI drivers. However, you do need the particular makefiles and some other stuff that is particular to the kernel that you’re compiling for; there’s simply no good way to get around this - Linux kernel modules _do_ need to be tailored specifically to the kernel in question, since interfaces may change and in particular the binary interface is actually not necessarily really the same for SMP and single-processor kernels.
Several Linux 2.6-based distributions no longer ship the necessary files as part of some running-kernel-customized source tree; instead they ship these files as part of the kernel package or possibly in a separate package. As an example, in Fedora Core 2, which I’m running, this is directly in the /lib/modules/<kernel-version-tag>/build directory (for most Linux 2.4 distros this just used to be a symlink to the source code directory, which might or might not have been prepared correctly).
Of course, the proof of the pudding is in the tasting, and the tasting in this case is the fact that you can read this e-mail. I _do not_ have a kernel source package installed, yet I was able to build the MADWiFi drivers and it works perfectly. (Currently using the WPA branch, however the situation was the same for the HEAD branch.) No thanks to me either; all I did was type ‘make’ and then ‘make install’ with the kernel in question running. (Unfortunately both steps needed root access; the first step shouldn’t really, and that might have be fixed recently in the Makefile - haven’t updated recently, but in order to work without write access to the kernel ‘build’ directory one apparently needs to use a new syntax in the makefile that was introduced in 6 or so.)
And from Greg Chesson,
The driver needs the kernel header files for compilation. That much is obvious. In order to make the driver readily buildable for either 2.4 or 2.6 kernels, a decision was made to use the kernel Makefiles. So… minimum answer is that the .config file, headers, and Makefiles are needed.
You could argue that we should have retained the original build procedure with madwifi-specific makefiles in the driver. However, the rapid pace of change with kernel build procedures when 2.6 came along made this an intractable problem for us.
I get 'uudecode : i386-elf.hal.o.uu : no end line'
You're using a revision older than 1535, you should upgrade. If you don't want to, you can still read this:
This entry was sent in by Jean Daniel Browne:
The HAL is a binary file encoded in ASCII for easy download (and because CVS doesn't like binaries). It is meant to be decoded with uudecode in the first steps of the building process.
It is likely that the problem does not come from your system nor from the code. What may be happening is that you retrieved the file with a non-unix software that converted the unix text file format to dos format. End of line are represented by the linefeed character in unix but represented with carriage return + linefeed in dos. uudecode is confused by the CR/LF at the end of the last line of the file because it only expects a LF character.
What you can do is select an option to download the file as is (with no conversion). Wincvs offers such an option (in “preferences” : “check out files with the unix LF”).
Or you can convert i386-elf.hal.o.uu back to unix style by deleting the carriage return character with any method you like (awk, sed, tr, vi, perl, dos2unix, emacs). The encoded HAL is in the madwifi/hal/linux/ directory. E.g.:
tr -d '\15' > i386-elf.hal.o.uu < hal.unix mv -f hal.unix i386-elf.hal.o.uu
You should then be ready to build the module.
Compiling madwifi for 64bit x86 fails with a message saying something like "relocatable linking from elf32-i386 to elf64-x86-64 not supported". Help?!
The exact error message looks like this:
ld: Relocatable linking with relocations from format elf32-i386 (/path/to/madwifi/ath_hal/hal.o) to format elf64-x86-64 (/path/to/madwifi/ath_hal/ath_hal.o) is not supported
Let’s have a look on what happens when Madwifi is getting built. The first module that is built is ath_hal.o, which contains the binary HAL code and some platform-specific glue code (see here for further explanation). Make doesn’t know (yet) that you’re trying to build code for 64bit x86 and hence uses the precompiled HAL for 32bit x86, while the platform-specific glue code gets compiled for 64bit x86 by your C compiler. When the linker tries to throw both code pieces together it had to mix 32bit and 64bit code, which isn’t supported - et voila, that’s the meaning of the error message as mentioned above.
All you have to do is to tell make you’re planning to build madwifi for 64bit x86. The simples way to do this is the following:
make TARGET=x86_64-elf
If you’re cross-compiling (for example you want to build 64bit code on a 32bit system) you most probably also need to specify TOOLPREFIX so that make is able to find the 64bit compiler suite. You can find more information on avaiable Makefile parameters in UserDocs/Makefile.
