From: miquels@traveler.cistron-office.nl (Miquel van Smoorenburg)
To: linux-kernel@vger.kernel.org
Subject: Re: Linus's include file strategy redux
Date: 16 Dec 2000 11:09:49 GMT [thread overview]
Message-ID: <91fiht$7ve$1@enterprise.cistron.net> (raw)
In-Reply-To: <91e0so$9bn$1@enterprise.cistron.net> <Pine.LNX.3.96.1001215194935.19208D-100000@tarot.mentasm.org>
In article <Pine.LNX.3.96.1001215194935.19208D-100000@tarot.mentasm.org>,
<ferret@phonewave.net> wrote:
>On 15 Dec 2000, Miquel van Smoorenburg wrote:
>
>> I think /lib/modules/`uname -r`/ should contain a script that
>> reproduces the CFLAGS used to compile the kernel.
>
>However it happens, the necessary information THAT I KNOW OF is:
>0) The kernel headers under linux/include
>1) The state information generated by running make configure ; make dep ;
>make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
>configure which does the same thing but adds packaging-specific metadata.
That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h
>A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
>will not always work, because:
>0) The destination may not even exist (if the kernel has been installed
>onto another machine)
Yes but in that case, how are you going to compile a module without
the kernel headers anyway. If you compiled a kernel on one
machine and you know that you want to be able to compile modules
on the second machine you need to copy over /usr/src/linux-x.y.z/include
as well.
>1) The destination has no metadata or has the WRONG metadata (if I've just
>compiled and installed 2.4.0-test11 on my i386, then am now building same
>for my sun4c)
As I said the kconfig script should do some simple sanity checks-
compare version and architecture at least.
>I have been recently told that a full copy of kernel headers and metadata
>in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
>who informed me of this hasn't yet shown why.
Because lots of use have a small root file system of just 30 MB ?
Hmm, but as soon as you start thinking about cross-compiles etc
you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR,
NM etc etc. Yuck. It would probably be better to put all that info
in /usr/src/linux/Config.make, and use the current "build" symlink.
A module makefile would then look like this:
#! /usr/bin/make -f
# You might want to point BUILD somewhere else.
BUILD = /lib/modules/$(shell uname -r)/build
include $(BUILD)/Config.make
module.o:
$(CC) $(CFLAGS) -c module.c
Ah yes, this is probably a much better approach then a kconfig script
Mike.
--
RAND USR 16514
-
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 11:40 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 [this message]
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
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='91fiht$7ve$1@enterprise.cistron.net' \
--to=miquels@traveler.cistron-office.nl \
--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