Jesse Hall wrote:
>
> 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.
I'll file this one away in my list of tips. It should mix well with
using non-sym links for the /usr/include/linux/ and similar include
directories.
D. Stimits, stimits@xxxxxxxxxx
>
> 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.
> >
|