Re: Egna kernel-headers och dependencies
many@unx.se skrev:
> many@unx.se skrev:
>> I går skapade jag egna debian-paket med make-kpkg för kärnan 2.6.5.
>> Jag har gjort paket för kernel, headers och docs. Nya kärnan är
>> installerad och fungerar till synes perfekt.
>>
>> Men hur beter jag mig för att header-paketet ska bli en del av systemet?
>> När jag installerar det så hamnar filerna
>> /usr/src/kernel-headers-nånting
>> och inte i /usr/include/*
>>
>> Dessutom så säger lib6-dev att det kräver linux-kernel-headers som en
>> dependency, och då installeras version 2.5.9-nånting...
Hej Mackan!
Välkommen till Debian!
Det skall vara så. Orsaken är att utvecklingsmiljön inte skall "förstöras"
när man installerat en ny kärna, efterssom det ändå är glibc som är
användarprogrammens gränssnitt mot kärnan. Dom få program som verkligen
behöven specifika kernel-headerfiler måste explicit specificera det genom
att specificera -I/usr/src/kernel-headers-<version> eller liknande för en
viss specifik kernel-version. Dom andra använder helt enkelt
-I/usr/src/linux/include istället.
Följande är saxat från
/usr/share/doc/kernel-package/README.headers:
Traditional two symlink approach
=========== === ======= ========
Under libc5, it was standard for part of the user interface to
libc to be exported from the kernel includes, via /usr/include/linux
and /usr/include/asm. Traditionally, this was done by linking those
two directories to the appropriate directories in
/usr/src/linux/include. This is the method documented in the install
instructions for the kernel sources, even today.
Why that is bad
=== ==== == ===
Kernel headers no longer make sense exporting to user space
(in early days of Linux, that was not true). It is beginning to get
harder to synchronize the libc and the kernel headers as in the old
days; now linking with the latest kernel headers may subtly break new
code since the headers linked with are different from the compiled
library. In addition, the specter of programs breaking with new
kernel headers was preventing needed new features from being added to
the kernel (and damping innovative experimentation in kernel
development) (see appendix A for details).
[...]
Consider this: Namespace contention between the C library and
the kernel (GNU libc is not a Linux only entity) Also, different
library versions want different #defines and type defines in
different places. Some libraries want to define their own FD_SET,
while older ones want to get the kernel ones.
This is a mess. Kernel headers can't change anymore, even when
the interfaces are not really changing, since one does not know
what breaks in userland libraries.
The solution is to separate out the two sets of header files:
the kernel uses one frequently changing set, and a set of headers is
provided from a known good kernel version, which is tested, known to
be stable, 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).
... och detta är vad Linus säger om saken:
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.
[...]
/Martin Leben
--
Remove dashes and numbers (if any) to get my real email address.
I subscribe to the mailing lists i write to. Please don't CC me on replies.
Reply to: