On Tuesday 05 June 2007, Vegard Nossum wrote:
You also need to take some care about the gcc arguments that you pass.
E.g. passing -DMODULE when building the precompiled header means that
you can't use that .pch when you build a file where you don't pass
-DMODULE.
So does it make sense
On Tuesday 05 June 2007, Sam Ravnborg wrote:
It's stuff like this that worries me..
In the kernel we rely on a lot of things - more than in usual projects.
And one thing we have established in the 2.6 kernel is a trust in the
build system. If you change something kbuild will recompile
On Thursday 31 May 2007, Vegard Nossum wrote:
By the way, according to the GCC manual [1], Only one precompiled
header can be used in a particular compilation, which, if I interpret
it correctly, might make header precompilation useless for the kernel
anyway. But here's my attempt (I hope the
On Dunnersdag 10 Februar 2005 17:51, Christoph Hellwig wrote:
Linking it into vmlinux would increase vmlinux size, which is exactly
what the Kerntypes approach is trying to avoid.
Well, building the whole kernel with -gstabs or similar will enlarge
the binary by factor ten or more, which should
On Dienstag, 3. August 2004 19:22, Anupam Kapoor wrote:
doing both of these seems to be (at least to me) non-trivial. ideally,
i would like to just invoke 'make' in the source dir, and have both
foo.ko and foo-debug.ko built.
i have tried this:
obj-m := foo.o foo-debug.o
Try adding a
On Wednesday 14 August 2002 07:49, Peter Samuelson wrote:
[Kai Germaschewski]
It comes of the cost of testing for the architecture, since
e.g. s390 does not want to include most of drivers/*, but that means
we'd actually collect this knowledge at a centralized place.
What we need is an
On Tuesday 04 June 2002 05:54, Keith Owens wrote:
Please try this:
+override KBUILD_OBJTREE := $(shell echo $(KBUILD_OBJTREE) | tr
'\t' '
' | sed -e 's:/* *$$:/:')
Yep, that does it.
Arnd
___
Don't miss the
On Tuesday 04 June 2002 06:53, Keith Owens wrote:
kbuild-2.5-common-2.5.20-2.
I still have a link order problem in -common-2.5.20-[12] that I noticed
after I eventually tried to run my kbuild-2.5 kernel.
The initialization code in arch/i386/pci needs the pci_bus_type object
from
On Monday 03 June 2002 07:31, Keith Owens wrote:
Added kbuild-2.5-common-2.5.20-1 and kbuild-2.5-i386-2.5.20-1, upgrade
to 2.5.20. No core changes.
I needed the small patch below to get the kernel to link in my configuration,
trivial port of the changed Makefile.
For the s390 architecture,
On Friday 24 May 2002 09:41, Dominik Brodowski wrote:
Keith: Do you have any plan on how to split kbuild-2.5 up in manageable
pieces Linus likes? Haven't really looked closely at the code, but could
the new-style Makefiles.in somewhat easily be transformed to the previous
per-directory
On Tuesday 14 May 2002 01:31, Keith Owens wrote:
- sed -e s:\(.*\):cp -fa \1 $(module_dir)kernel/\1: $(objfile
.tmp_vmlinux_modules) | $(KBUILD_SHELL)
+ sed -e s:\(.*\):cp \1 $(module_dir)kernel/\1: $(objfile
+.tmp_vmlinux_modules) | $(KBUILD_SHELL)
I thought you'd leave the
On Saturday 11 May 2002 11:32, Keith Owens wrote:
kbuild-2.5-common-2.5.15-2
Changes from common-2.5.15-1.
Add -f to cp/mv. Mainly to cope with aic7xxx shipping files and
overwriting them with the same name.
It seems you introduced a new bug by adding '-a' to cp as well as '-f',
On Friday 05/09/02 06:11 AM, Paul wrote:
I will try to reproduce the problem (I have made one attempt already
but failed). I think it happened when I removed (or possibly just
moved) a base_target.
I have also seen the problem before and tried unsuccessfully to reproduce it.
I thought it
Hi!
I'm doing the port of kbuild 2.5 for the arch/s390 and ach/s390x. I already
have a
working (mostly, it's currently against our internal tree only) patch, but
still have
a few questions/problems:
1. My vmlinux.lds.i depends on a config symbol (CONFIG_SHARED_KERNEL), so I
#included
config.h
14 matches
Mail list logo
