> Ok. this is beginning to confuse me.
>
> glibc install:
>
> Note that `/usr/include/net' and `/usr/include/scsi' should *not* be
> symlinks into the kernel sources. GNU libc provides its own versions
> of these files.
>
> kernel docs:
>
> Several distributions have taken their own copies of these files and placed
> them in /usr/include/scsi which is where "#include <scsi/sg.h>" would go
> looking. The directory /usr/include/scsi _should_ be a symbolic link to
> /usr/src/linux/include/scsi/ . It was is Redhat 5.1 and 5.2 but it is
> not is Redhat 6.0 . Some other distributions have the same problem. To
> solve this (as root) do the following:
>
> # cd /usr/include
> # mv scsi scsi_orig
> # ln -s ../src/linux/include/scsi scsi
>
> Now, the question that I have is... What in the name of god am I to do?
Well, roughly speaking glibc and Debian and recent RedHat and recent SuSE
are right, and the author of scsi-generic.txt is mistaken.
[One does not recompile all one's software when upgrading kernels.
Apparently ordinary software is independent of the includes used.
In case the includes really do matter, one gives -I<some-linux-include-dir>
to get the includes from one particular kernel version (and then knows
that the program obtained that way may break when another kernel is used).]
Note that including linux kernel includes is meaningful only to get
kernel interface definitions. In particular, if one only needs constants
defined in the SCSI standard then a private include file is just as well
as <linux/../scsi/scsi.h>.
If I am not mistaken, glibc-2.0.5 does not have <scsi/*.h>;
glibc-2.0.6 has <scsi/sg.h> but no other includes;
glibc-2.1 has both <scsi/sg.h> and <scsi/scsi.h>.
Thus, for most purposes, a recent glibc should be fine.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/