From: offer@sgi.com (richard offer)
Message-Id: <10012151850.ZM22906@sgi.com>
Date: Fri, 15 Dec 2000 18:50:41 -0800
To: linux-kernel@vger.kernel.org
Subject: Re: Linus's include file strategy redux
In-Reply-To: <91e0vj$b6alr$1@fido.engr.sgi.com>
In-Reply-To: <20001215152137.K599@almesberger.net> <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>
Organization: Silicon Graphics Inc., Mountain View, CA
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org

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/