Hi Colin, > > The seemingly obvious would be to change this to :- > > > > gcc -D__KERNEL__ -DMODULE -DMODVERSIONS -include /usr/src/kernel-headers-2.4.18-bf2.4/include/linux/modversions.h -Wall -Wstr ict-prototypes -O2 -m486 -c modulename.c -I/usr/src/kernel-source-2.4.18-bf2.4/include > > > > ...only there isn't any kernel-source-2.4.18-bf2.4 on the issue DVD. > > How am I supposed to proceed? > > I think you want kernel-headers-2.4.18-bf2.4. There's such a package in > stable.
OK, that worked. Thanks. > > BTW It seems from my experiences that Linux release systems are > > generally buggy! I had a very similar experience with Red Hat 9 a > > couple of months ago, and in that instance the recommendation was to > > install the latest version of the kernel, plus the latest version of > > the kernel source, and that would clear things up. In the event it > > caused a build error which I had to find my way around by creating > > links in the /usr source and include trees, specifically for a 'linux' > > directory to be a link to a specific linux directory and for an 'asm' > > directory to be a link to a specific asm includes directory. > > Making /usr/include/linux and /usr/include/asm symlinks is Very Bad. > There are three issues involved: > > * glibc needs to have a set of kernel headers for its own use, which > live in /usr/include/linux and /usr/include/asm. These MUST match > the kernel version against which glibc was compiled, and you > shouldn't try to make them match the kernel version you're running. So you're saying that the binary GCC I'm running, requires the very mainstream-sounding path /usr/include/linux to be dedicated for its own use, to refer to *while its executing*, and yet my own need for access to the headers relevant to all of my actual work here, need to be stuck off on some backwater pathname like /usr/src/kernel-headers-2.4.xxx? If an executable must necessarily have access to parts of its own constituent source (and I've almost never seen an inescapable need for this, in a good long career) it would have been more elegant for the binary GCC to have its own specific headers installed in its own dedicated area, perhaps called /usr/src/gcc-version-XXX/include/linux. Then the developer's access to kernel headers could be along the obvious /usr/include/linux path. OK, so that's not how it's been done. More's the pity. > * Third-party kernel modules need to build against the headers from > the kernel you're running. Those can live anywhere; modern kernel > packages set a /lib/modules/`uname -r`/build symlink so that modules > can find them more easily, but you do need to have the appropriate > kernel-headers package installed. Useful background info. > * Normal user programs must not include anything in /usr/include/linux > or /usr/include/asm directly, since those headers are generally not > guaranteed to be suitable for use from userspace directly, only via > glibc. If need be, programs should copy the values of the constants > they need, which isn't very clean but is necessary. I didn't need to be told any of that! I'm not talking about /usr/include/asm. What I needed in RH9 was for my build directory to contain a symlink to the hardware-specific asm-xxxx directory in the /usr/include tree. It has now transpired that this link is unnecessary when I point the compiler at the RH9 equivalent of /usr/src/kernel-headers-2.4.xxx. Again, thanks. Cheers, Mike --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
