The NVidia Makefiles are designed to handle this correctly. Try
$ make SYSINCLUDE=/usr/src/linux-2.4/include
(adjust path as appropriate). This will pull all kernel headers (and
versioned symbols if enabled) from the specified directory. This is
documented in their README.
I use both 2.2 and 2.4 kernels, and this is far easier than switching
symlinks in /usr, or even switching a /usr/src/linux symlink.
Jesse
On Fri, 22 Jun 2001, D. Stimits wrote:
> Keith Owens wrote:
> >
> > On Thu, 21 Jun 2001 22:38:20 -0600,
> > "D. Stimits" <stimits@xxxxxxxxxx> wrote:
> > >One snag you might be running into is that RH 7.1 makes directories
> > >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies
> > >of their kernel. You probably want to cd to /usr/include, and rename
> > >(mv) asm, linux, and scsi, to some backup. Then also expand on their
> > >symbolic links at /usr/src/.
> >
> > Please do not do that. Linus and other kernel maintainers fought a
> > long and hard battle to stop distributions making symlinks from
> > /usr/include to /usr/src/linux, or to any other active kernel.
> >
> > The files in /usr/include are for user space applications that need a
> > stable set of includes. These must not change depending on which
> > kernel you have installed this week.
>
> Conceptually, in most practical ways, I understand this. But in the case
> of device drivers or hardware that might be compiled, if it does
> something like #include <linux/something.h>, and something.h has changed
> in the kernel, it could cause other problems than just compile
> incompatibilities. For example, modules that are compiled separately
> from the kernel (because they are not patched in to the kernel or
> otherwise not part of the kernel source tree, such as cvs releases of
> many modules). If all of the writers of kernel-dependent code
> (distributed separately from a kernel) use a #include with an absolute
> path, e.g.:
> #include "/usr/src/linux/include/something.h"
>
> ...then it would always work as advertised. It sounds like maybe it is a
> good idea to keep the headers constant, but it also seems that it will
> cause older software that is hardware dependent to break if it wasn't
> written with this in mind. I have not grepped the NVidia code, but I
> wonder if they have used the format:
> #include <linux/something.h>
> #include <asm/something.h>
>
> In any case, I hadn't heard about this till now, so I guess it is time
> to change then.
>
> D. Stimits, stimits@xxxxxxxxxx
>
> >
> > User space code cannot assume that it has current kernel headers,
> > instead they get headers that match glibc and other tools. User space
> > code should not read kernel headers directly, instead the package
> > should contain a copy of the required definitions. It is almost always
> > a bad idea for user space applications to depend on kernel headers.
> > Even code like modutils that hooks right into the kernel has its own
> > copy of the required kernel headers, it is the only way to ensure that
> > it ca be compiled on any kernel.
> >
> > Kernel based code must be compiled against kernel headers, not against
> > /usr/include. The kernel makefiles try to avoid reading from anything
> > outside the kernel.
>
|