Carl Wilhelm Soderstrom wrote:
> don't do it in /usr/src. no good reason to. do the config and build in
> your
On Thu, Nov 15, 2001 at 09:12:57PM -0600, eric wrote:
> The good reason to is that /usr/include/asm and /usr/include/linux
> both should refer to the kernel that you are working with.
Define "working with". Are you recompiling glibc every time you compile
a new kernel? /usr/include/asm and /usr/include/linux should point to
the headers that were used to compile glibc. Disagree with me? There's
a number of documents to support this argument. The best explaination
of which can be found in the Debian 'kernel-package' documents. The
file is called README.headers, and it is a heafty read, but well worth
it.
http://people.debian.org/~srivasta/rules/kernel/README.headers
I'm including Linus's personal, yet "unofficial", statement on the
matter. I say a bit more following the exerpt.
----------------------------------------------------------------------------
>> "David" == David Engel <david at sw.ods.com> said on Mon, 24 Feb 1997
>> "Linus" == Linus Torvalds said on Mon, 24 Feb 1997
David> Hi Linus,
David> No matter how well we try to explain ourselves, the symlinks issue
David> keeps coming up. Would you mind if we used your message below in
David> our responses?
Linus> Sure. Don't make it "the word of God" - please point out that
Linus> it was a off-the-bat personal reply to a question concerning
Linus> this, and while I'm more than happy to have the email
Linus> circulated it shouldn't be seen as a "official" document in any
Linus> way..
Linus> Linus
---------------------------------------------------------------------------
>> "Linus" == Linus Torvalds said on Wed, 22 Jan 1997:
Linus> The kernel headers used to make sense exporting to user space,
Linus> but the user space thing has grown so much that it's really not
Linus> practical any more. The problem with Debian is just that they
Linus> are different, not that they are doing anything wrong. That
Linus> leads to differences between the distributions, and that in
Linus> turn obviously can result in subtle problems.
Linus> As of glibc, the kernel headers will really be _kernel_
Linus> headers, and user level includes are user level
Linus> includes. Matthias Ulrich did that partly because I've asked
Linus> him to, but mainly just because it is no longer possible to try
Linus> to synchronize the libc and the kernel the way it used to
Linus> be. The symlinks have been a bad idea for at least a year now,
Linus> and the problem is just how to get rid of them
Linus> gracefully. Personally, I'm counting on glibc, which we are
Linus> already using on alpha.
---------------------------------------------------------------------------
Linus goes on with multiple examples why symlinking is BAD. There's a
wonderful option available to all gcc(1) users called "-I". It allows
you to add paths of include directories so that gcc can find the header
files specified in the "#include" preprocessor directive. If you MUST
reference the headers of a specific kernel, for let's say a new kernel
module, then include that directory in the -I<directory> directive.
There is absolutely no reason to use symbolic links in
/usr/lib/{asm,linux} any longer. There hasn't been for some time now...
since 1996 in Linus' "unofficial" opinion. Why people haven't caught on
is a mystery to me.
You really should read the README.headers document. It's a good read.
--
Chad Walstrom <chewie at wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20011116/81a6e44e/attachment.pgp