Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Changes from Version 1 of FAQ/BuildProblems

Author:
matt (IP: 0.0.0.0)
Timestamp:
10/08/05 21:02:37 (14 years ago)
Comment:

created from the sf wiki

Legend:

Unmodified
Added
Removed
Modified
  • FAQ/BuildProblems

    v v1  
     1= FAQs on Building MADWiFI = 
     2 
     3== I get 'No rule to make target ''/lib/modules/{kernel_version}/build/.config'' == 
     4 
     5{{{/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: 
     6 
     7{{{ 
     8# cd /lib/modules/{kernel_version} 
     9# ln -s /usr/src/linux-{kernel_version} build 
     10# and to check it worked: 
     11# ls -al build 
     12}}} 
     13 
     14You should see something like this: 
     15 
     16{{{ 
     17lrwxrwxrwx 1 root root 21 Sep 22 17:12 build -> /usr/src/linux-{kernel_version} 
     18}}} 
     19 
     20If 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. 
     21 
     22You 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}}}. 
     23 
     24You can get the latest wireless extensions from: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/ although most recent kernels already have them. 
     25 
     26According to Felipe Saint-Jean, you also need to ensure that your kernel is built with SMP ({{{CONFIG_SMP}}}) support off. 
     27 
     28Jason Lewandowski also suggests restarting PCMCIA services, you may find this helps. 
     29 
     30== ath_hal.o does not exist. == 
     31 
     32You need to install the [http://www.gnu.org/software/sharutils/sharutils.html sharutils] for your distribution. If your distro doesn’t have such a package, it is {{{uuencode}}} and {{{uudecode}}} which you need. 
     33 
     34== I get, 'Unresolved symbols in _IEEE(something)', help! == 
     35 
     36You must make sure that you build your kernel with {{{CONFIG_MODVERSIONS=n}}}, thanks to Joe Milbourn for (inadvertantly) testing this! 
     37 
     38Also, Jon Bohlke points out that if you’ve patched the driver into your kernel source, you need your kenel to have IEEE.80211 in it’s config. 
     39 
     40== Why is the kernel source required to build Madwifi? == 
     41 
     42This answer is a mixture of mailing list discussion from Per Bjornsson and Greg Chesson. 
     43 
     44Contrary 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. 
     45 
     46Several 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). 
     47 
     48Of 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.) 
     49 
     50And from Greg Chesson, 
     51 
     52The 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. 
     53 
     54You 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. 
     55 
     56== I get 'uudecode : i386-elf.hal.o.uu : no end line' == 
     57 
     58This entry was sent in by Jean Daniel Browne: 
     59 
     60The 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. 
     61 
     62It 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. 
     63 
     64What 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”). 
     65 
     66Or 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.: 
     67 
     68{{{ 
     69tr -d '\15' > i386-elf.hal.o.uu < hal.unix 
     70mv -f hal.unix i386-elf.hal.o.uu 
     71}}} 
     72 
     73You should then be ready to build the module. 
     74 
     75== During compilation I see lots of warnings about undefined symbols, and loading the driver fails due to "unresolved symbols". == 
     76 
     77There are two seperate issues here, the most important one is the unresolved symbols errors. The warnings about undefined symbols are purely cosmetic. 
     78 
     79First, make sure your kernel if configured correctly, see: UserDocs/KernelConfig. 
     80 
     81Then, recompile the kernel if necessary and reboot with this new kernel. Remove old versions of the Madwifi modules if necessary, then recompile Madwifi. It should work now. 
     82 
     83== Compiling madwifi for 64bit x86 fails with a message saying something like "relocatable linking from elf32-i386 to elf64-x86-64 not supported". Help?! == 
     84 
     85The exact error message looks like this: 
     86 
     87{{{ 
     88ld: Relocatable linking with relocations from format elf32-i386 
     89(/path/to/madwifi/ath_hal/hal.o) to format elf64-x86-64 
     90(/path/to/madwifi/ath_hal/ath_hal.o) is not supported 
     91}}} 
     92 
     93Let’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. 
     94 
     95All 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: 
     96 
     97{{{ 
     98make TARGET=x86_64-elf 
     99}}} 
     100 
     101If 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.