From: offer@sgi.com (richard offer)
To: linux-kernel@vger.kernel.org
Subject: Re: Linus's include file strategy redux
Date: Fri, 15 Dec 2000 18:50:41 -0800 [thread overview]
Message-ID: <10012151850.ZM22906@sgi.com> (raw)
In-Reply-To: <91e0vj$b6alr$1@fido.engr.sgi.com>
In-Reply-To: <20001215152137.K599@almesberger.net> <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>
In article <91e0vj$b6alr$1@fido.engr.sgi.com> you write:
>In article <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>,
>LA Walsh <law@sgi.com> wrote:
>>It was at that
>>point, the externally compiled module "barfed", because like many modules,
>>it expected, like many externally compiled modules, that it could simply
>>access all of it's needed files through /usr/include/linux which it gets
>>by putting /usr/include in it's path. I've seen commercial modules like
>>vmware's kernel modules use a similar system where they expect
>>/usr/include/linux to contain or point to headers for the currently running
>>kernel.
>
>vmware asks you nicely
>
>where are the running kernels include files [/usr/src/linux/include" >
>
>And then compiles the modules with -I/path/to/include/files
>
>In fact, the 2.2.18 kernel already puts a 'build' symlink in
>/lib/modules/`uname -r` that points to the kernel source,
>which should be sufficient to solve this problem.. almost.
Don't get me started on that... The link points back to where the code
was when it was built, not where it is installed. This makes a difference
if you're building RPMs... in which case the link points back to (for
example) /usr/src/sgi/BUILD/linux-<version> and not
/usr/src/linux-<version>/.
And, top it all... once the build is completed the BUILD directory
is deleted.
Good Idea, but poorly thought out.
>I think /lib/modules/`uname -r`/ should contain a script that
>reproduces the CFLAGS used to compile the kernel. That way,
>you not only get the correct -I/path/to/kernel/include but
>the other compile-time flags (like -m486 etc) as well.
Anything that uses uname to work out what kernel is running doesn't work
if you're in a chrooted environment. Symlinks work better for this...if
all fails you can manage them manually during the build...
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] echo $ROOT
/work/root
[ changeling 2.2.15-#5 ] sudo chroot $ROOT
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] rpm -qa | grep kernel
kernel-headers-2.2.16-3
kernel-2.2.16-3
Trust me, $ROOT does not include 2.2.15....
>Mike.
richard.
-----------------------------------------------------------------------
Richard Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__________________________________________http://reality.sgi.com/offer/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-16 3:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <91gr99$bs81o$1@fido.engr.sgi.com>
2000-12-14 23:55 ` Linus's include file strategy redux LA Walsh
2000-12-15 0:14 ` Miquel van Smoorenburg
2000-12-15 0:17 ` Alexander Viro
2000-12-15 0:39 ` Miquel van Smoorenburg
2000-12-15 0:33 ` Alan Cox
2000-12-15 0:48 ` Alexander Viro
2000-12-15 0:56 ` David Riley
2000-12-15 1:05 ` Alexander Viro
2000-12-15 4:24 ` ferret
2000-12-16 11:30 ` Marcus Sundberg
2000-12-15 14:57 ` Kurt Roeckx
2000-12-15 15:23 ` Dana Lacoste
2000-12-15 22:28 ` Alex Buell
2000-12-16 22:41 ` Peter Samuelson
2000-12-18 15:51 ` Dana Lacoste
2000-12-18 17:08 ` Peter Samuelson
2000-12-18 19:32 ` David Schleef
2000-12-18 17:04 ` richard offer
2000-12-19 5:16 ` Peter Samuelson
2000-12-15 0:15 ` Alexander Viro
2000-12-15 7:21 ` LA Walsh
2000-12-15 11:05 ` Chmouel Boudjnah
2000-12-15 14:21 ` Werner Almesberger
2000-12-15 17:15 ` ferret
2000-12-15 17:46 ` Werner Almesberger
2000-12-15 20:29 ` Joe deBlaquiere
2000-12-15 21:27 ` Werner Almesberger
2000-12-15 22:58 ` Joe deBlaquiere
2000-12-15 23:56 ` Werner Almesberger
2000-12-16 22:50 ` Peter Samuelson
2000-12-17 0:04 ` Joe deBlaquiere
2000-12-17 2:05 ` Peter Samuelson
2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg
2000-12-16 4:04 ` ferret
2000-12-16 11:09 ` Miquel van Smoorenburg
2000-12-16 17:20 ` ferret
2000-12-17 0:21 ` J . A . Magallon
2000-12-16 23:10 ` Peter Samuelson
2000-12-17 1:15 ` Miquel van Smoorenburg
2000-12-17 2:18 ` Peter Samuelson
2000-12-15 21:21 ` Werner Almesberger
2000-12-15 21:36 ` LA Walsh
2000-12-15 22:48 ` J . A . Magallon
2000-12-15 23:47 ` Werner Almesberger
2000-12-16 4:11 ` ferret
2000-12-16 2:50 ` richard offer [this message]
2000-12-16 4:22 ` What about 'kernel package'? was: " ferret
2000-12-15 19:35 ` Matt D. Robinson
2000-12-15 21:36 ` Werner Almesberger
2000-12-18 17:48 Petr Vandrovec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10012151850.ZM22906@sgi.com \
--to=offer@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox