On Sun, Jan 07, 2001 at 01:30:15PM +0100, Robert Rakowicz wrote:
> ist das denn so richtig daß bei Debian ( kann nur von meiner LinuxLand
> Potato sprechen ) sich die Header des Kernels im /usr/include/linux
> befinden ? Ich bin natürlich voll auf die Nase gefallen, da ich gehe
> immer davon aus des es ein Link auf /usr/src/linux/include/linux ist.
Siehe http://www.linuxfaq.de/f/cache/57.html, unten gedumped.
Sorry für die Formatierung (w3m ist - natürlich - schuld. :)
Titel
[Suche] [Darstellung]
(Answer) (Category) Linux User FAQ : (Category) Programmierung unter Linux : (Category)
Tips für Selber-kompilieren von Software :
Was ist der Unterschied zwischen `/usr/src/linux/include' und `/usr/include/
linux'?
Achtung Fortgeschrittenen-Info
Warum gibt es `/usr/src/linux/include' (in den Kernelquellen) und `/usr/include/
linux' (in dem System-Includeverzeichnis)? Welches sollte ich benutzen? Warum
kompilieren einige Programme nicht, oder meckern über 'falsche Kernel-Header'?
Hier ist eine etwas ältere, aber noch aktuelle Erklärung, wozu es diese beiden
Verzeichnisse gibt, warum sie getrennt wurden, woher sie kommen, und warum seit
einiger Zeit aus `/usr/include/linux/errno.h' die letzte Zeile aus der folgenden
Liste
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
...
#define EMACS 666 /* Editor too large */
herausgenommen wurde. ;-)
Here is the rationale of the `/usr/include/linux' vs. `/usr/src/linux/include/
linux' issue. (sorry, I don't have any reference to this, so I have to include
all the text here) Basically the kernel headers match the kernel. The `/usr/
include' headers match the program development tools. This allows to separate
kernel and libc development.
Here is the story:
The headers were included in `libc5-dev' after a rash of very buggy alpha kernel
releases (1.3.7* or something like that) that proceeded to break compilations,
etc. Kernel versions are changed far more rapidly than libc is, and there are
higer chances that people install a custom kernel than they install custom LIBC.
LIBC6 includes it's own version of `/usr/include/linux' and friends form the
beginning (that is, this is no longer a `Debian' only feature, the upstream
version has moved to this scheme as well).
>> "Linus" == Linus Torvalds said on Wed, 22 Jan 1997:
The kernel headers used to make sense exporting to user space, but the user space
thing has grown so much that it's really not practical any more. The problem with
Debian is just that they are different, not that they are doing anything wrong.
That leads to differences between the distributions, and that in turn obviously
can result in subtle problems. As of GLIBC, the kernel headers will really be
_kernel_ headers, and user level includes are user level includes. Matthias
Ulrich did that partly because I've asked him to, but mainly just because it is
no longer possible to try to synchronize the libc and the kernel the way it used
to be. The symlinks have been a bad idea for at least a year now, and the problem
is just how to get rid of them gracefully. Personally, I'm counting on GLIBC,
which we are already using on alpha. Just to give you some idea of exactly why
the includes really can't be handled by simple symlinks: the main problem is
version skew. Lots of people want to upgrade their library without affecting the
kernel, and probably even more people want to be able to upgrade their kernel
without affecting their compilation environment. Right now doing that has been
extremely fragile. Just to give _one_ example of why the symlinks are bad:
NR_OPEN and fd_set. I have had no end of problems making NR_OPEN larger in the
kernel, exactly _because_ of the damn sym-links.
If I just make NR_OPEN larger (the right thing to do), the problem is that people
with old libraries will now compile against a header file that doesn't match the
library any more. And when the library internally uses another NR_OPEN than the
new program does, "interesting" things happen. In contrast, with separate header
files, this doesn't make any difference. If I change NR_OPEN in the kernel, the
compilation environment won't notice until the library and associated header
files are changed: thus the user will contine to compile with the old values, but
because we'll still be binary compatible, the worst thingthat happens is that new
programs won't take advantage of new features unless the developer has upgraded
his library. Compare that to breaking subtly. NR_OPEN is just _one_ example, and
actually it's one of the easier ones to handle (because the only thing that
really makes much of a difference when it comes to NR_OPEN is the fd_set size --
but it certainly bit some people). Another major problem is name-space pollution:
the POSIX/ANSI/XOPEN rules are not only complex, but they are actually
contradictory too. And the kernel header files really can't reasonably support
all of the intricacies very cleanly. One specific example of why we want separate
header files for libraries and kernel is offered by glibc: Matthias wanted to
have a sigset_t that will suffice for the future when the POSIX.1B realtime
signals are implemented. But at the same time he obviously wants to be able to
support programming on Linux-2.0 and the current 2.1 that do not have that
support. The only reasonably clean way to handle these kinds of problems is to
have separate header files: user programs see a larger sigset_t, and then the
library interaction with the kernel doesn't necessarily use all of the bits, for
example. Then later, when the kernel support is actually there, it's just a
matter of getting a new shared library, and voila, all the realtime signals work.
The symlink approach simply wouldn't work for the above: that would have required
everybody who uses the library to have a recent enough kernel that whatever magic
all the above entails would be available in the kernel header files. But not only
don't I want to pollute the kernel header files with user level decisions, it's
actually possible that somebody wants to run glibc on a 1.2.x kernel, for
example. We definitely do not want him to get a 32-bit sigset_t just because he
is happy with an old kernel. Anyway, this email got longer than intended, but I
just wanted to make clear that the symlinks will eventually be going away even in
non-Debian distributions. Debian just happened to do it first -- probably because
Debian seems to be more interested in technical reasons than any old traditions.
And technically, the symlinks really aren't very good. The only reason for the
symlinks is to immediately give access to new features in the kernel when those
happen. New ioctl numbers etc etc. That was an overriding concern early on: the
kernel interfaces expanded so rapidly even in "normal" areas that having the
synchronization that symlinks offered was a good thing.
However, the kernel interfaces aren't really supposed to change all that quickly
any more, and more importantly: the technical users know how to fix things any
way they want, so if they want a new ioctl number to show up they can actually
edit the header files themselves, for example. But having separation is good for
the non-technical user, because there are less surprises and package
dependencies.
Anyway, something like the patch that David suggested will certainly go in,
although I suspect I'll wait for it to become "standard" and the glibc first real
release to take place.
Add to that the fact that few programs really need the more volatile elements of
the header files (that is, things that really change from kernel version to
kernel version), [before you reject this, consider: programs compiled on one
kernel version usually work on other kernels].
So, it makes sense that a set of headers be provided from a known good kernel
version, and that is sufficient for compiling most programs, (it also makes the
compile time environments for programs on debian machines a well known one,
easing the process of dealing with problem reports), the few programs that really
depend on cutting edge kernel data structures may just use -I/usr/src/linux/
include (provided that kernel-headers or kernel-source exists on the system).
Most programs, even if they include <linux/something.h>, do not really
depend on the version of the kernel, as long as the kernel versions are not too
far off, they will work. And the headers provided in `libc5-dev' (and
`libc6-dev') are just that.
`libc5-dev' is uploaded frequently enough that it never lags too far behind the
latest released kernel. libc6 has totally disconnected the included headers from
kernel headers.
There are two different capabilities which are the issue, and the kernel-packages
and `libc{5,6}-dev' address different ones:
- The kernel packages try tp provide a stable, well behaved kernel and modules,
and may be upgraded whenever there are significant advances in those
directions (bug fixes, more/better module support, etc). These, however,
may not have include files that are non-broken as far as non-kernel programs
are concerned, and the quality of the development/compilation environment is
not the kernel packages priority (Also, please note that the kernel
packages are tied together, so kernel-source, headers, and image are produced
in sync)
- Quality of the development/compilation environment is the priority of
`libc{5,6}-dev' package, and it tries to ensure that the headers it provides
would be stable and not break non-kernel programs. This assertion may fail
for alpha kernels, which may otherwise be perfectly stable, hence the need
for a different set of known-good kernel include files.
[Diesen Eintrag erweitern]
Vorhergehende: (Answer) Was wird wohin installiert, kann ich es sauber
wieder entfernen?
Nächste: (Answer) "Hilfe! Mein Programm ist abgestürzt!" oder "Eine
kleine Segmentation Fault Einführung"
Dieses Dokument ist: http://www.linuxfaq.de//cgi-bin/fom?file=57
[Suche] [Darstellung]
Dies ist eine Faq-O-Matic 2.710.
This FAQ administered by Jens Benecke
--
A: "Ist [...] noch am Leben?"
B: "Sie wurde zusammen mit ihrem Mann begraben."
A: "Das beantwortet meine Frage nicht!"
http://www.hitchhikers.de/ - Die kostenlose Mitfahrzentrale für ganz Europa
Attachment:
pgpRTmvHRT5DN.pgp
Description: PGP signature