lkml.org 
[lkml]   [1997]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compile error under 2.1.46
On Jul 23, Philip Blundell wrote
> >While on the subject, I was wondering also if it is now time to
> >change the 2.1.x series README file. It currently says:
> >
> >" - Make sure your /usr/include/asm, /usr/include/linux, and /usr/include/scsi
> > directories are just symlinks to the kernel sources:
> >
> > cd /usr/include
> > rm -rf asm linux scsi
> > ln -s /usr/src/linux/include/asm-i386 asm
> > ln -s /usr/src/linux/include/linux linux
> > ln -s /usr/src/linux/include/scsi scsi
> >"
> >
> >If you happin to have GNU libc installed this is not a good thing. User
> >space apps shouldn't use the kernel headers. If they need kernel header
> >type stuff (like compiling pcmcia tools for instance) they should
> >provide their own local copy. Any chance of getting this changed?
>
> /usr/include/linux is needed for libc5 though, and it doesn't break anything under glibc that would otherwise work.
>
> p.


While this is true, the real answer is that libc5 should include its
own kernel headers that are seperate from the kernel. User space
applications should never use kernel headers anyway. If they absolutly
_must_ include a kernel header, they should have their own copy
instead of relying on the kernel header. (Debian already does this BTW)


Quoting from the GNU libc FAQ, Question 21:

[Q21] ``On Linux I've got problems with the declarations in Linux
kernel headers.''

[A21] On Linux, the use of kernel headers is reduced to a very
minimum. Besides giving Linus the possibility to change the headers
more freely it has another reason: user level programs now do not
always use the same types like the kernel does.

I.e., the libc abstracts the use of types. E.g., the sigset_t type is
in the kernel 32 or 64 bits wide. In glibc it is 1024 bits wide, in
preparation for future development. The reasons are obvious: we don't
want to have a new major release when the Linux kernel gets these
functionality. Consult the headers for more information about the changes.

Therefore you shouldn't include Linux kernel header files directly if
glibc has defined a replacement. Otherwise you might get undefined
results because of type conflicts.

-Erik

--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.284 / U:0.448 seconds]
©2003-2014 Jasper Spaans. Advertise on this site