-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Oops, hit encrypt instead of sign.
Release 2.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download
release 2.0.
... You know what they say about .0 releases ... User beware.
This announcement is for the base kbuild 2.5 code, i386 against 2.4.16.
It uses 2.4.16 because that gives a useful comparison against the
previous release and a decent branch point from kernel 2.4 to 2.5.
Patches for other architectures and kernels will be out in the next few
days, it takes time to generate and test patches for multiple
architectures against different kernel trees.
http://marc.theaimsgroup.com/?l=linux-kernel&m=99725412902968&w=2
contains information about the base release of kbuild 2.5.
Changelog:
New, faster core code, thanks to Larry McVoy for providing the
memory mapped database code.
Patches are now split into core (kernel independent), common
(architecture independent but kernel dependent) and arch
(architecture and kernel dependent) files. The core patch applies
to all kernels, both 2.4 and 2.5. The common and arch files apply
to specific kernels and hardware.
Other than being split into separate patches, kbuild 2.5 for the common
and i386 directories is almost unchanged from release 1.12. Tom
Duffy's patch for drivers/sbus/{audio,char}/Makefile.in has been
included. There are some minor changes where the more rigorous error
checking of this release found errors in kbuild 2.4 Makefiles.
The real change is the complete rewrite of the core code. Instead of
using a text file that is read by every compile step (slow!), kbuild
2.5 uses Larry McVoy's memory mapped database from BitKeeper (mdbm is
both GPL and BKL).
<strong><gloat>
Full 2.4.16 .config, everything that compiles built in. 4 x Pentium
III (Cascades) @700MHz, 5600 Bogomips, 1Gb RAM, SCSI, 2.4.17-xfs.
kbuild 2.4:
make oldconfig 0:07
make dep 0:37 (make -j dep is unsafe on some architectures)
make -j8 bzImage modules 14:16
Total 15:00
make -j8 bzImage modules 2:10 (second run, no changes, spurious rebuilds)
kbuild 2.5:
make -j8 oldconfig installable 8:51 (no make dep needed :)
make -j8 oldconfig installable :14 (second run, no changes)
</gloat></strong>
More accurate kernel build, easier to write and understand Makefiles,
30% faster than kbuild 2.4. Now the nay-sayers will have to find
something else to complain about!
I have not tried this release of kbuild 2.5 with a recent version of
CML2. It used to work on CML2 1.9.15, but probably needs some work for
the latest CML2. Note that kbuild 2.5 and CML2 are independent, each
can function without the other, complaints about CML2 have nothing to
do with kbuild 2.5.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE8rYnPi4UHNye0ZOoRArydAJ0SJk5jLqarn1pXtmX0JTsrPJKQSgCfYBLW
dD/osGKC7/q3SSlIxVXUEQA=
=gZmM
-----END PGP SIGNATURE-----
Keith Owens <[email protected]> writes:
>
> More accurate kernel build, easier to write and understand Makefiles,
> 30% faster than kbuild 2.4. Now the nay-sayers will have to find
> something else to complain about!
I assume with kbuild 2.4 you mean the current makefiles. How does it
compare at a single threaded build without -j ?
You seem to have written an awful lot of code just to build something.
Perhaps it would have been easier to just replace make completely with a
custom builder @)
-Andi
On 05 Apr 2002 14:01:13 +0200,
Andi Kleen <[email protected]> wrote:
>Keith Owens <[email protected]> writes:
>
>>
>> More accurate kernel build, easier to write and understand Makefiles,
>> 30% faster than kbuild 2.4. Now the nay-sayers will have to find
>> something else to complain about!
>
>I assume with kbuild 2.4 you mean the current makefiles. How does it
>compare at a single threaded build without -j ?
On a smaller config (full config takes too long when single threaded).
kbuild 2.4:
make oldconfig dep bzImage modules 6:25
make bzImage modules (no changes) 0:22
kbuild 2.5:
make oldconfig installable 4:45
make installable (no changes) 0:16
>You seem to have written an awful lot of code just to build something.
>Perhaps it would have been easier to just replace make completely with a
>custom builder @)
Would not have helped. Apart from all the people who complain about
needing extra tools to build the kernel (remember the Python wars for
CML2?), the kernel build has some really nasty requirements :-
* Most dependencies are not listed. kbuild has to work out which
sources depend on which headers, sometimes sources include other
sources.
* 2,200+ config options, each of which can affect as little as one file
or as much as the entire kernel. kbuild has to work out what each
config option affects.
* Changing a config option must only rebuild the affected targets, not
the entire kernel.
* Changing a command must rebuild only the affected targets, not the
entire kernel.
* You can change a command from the makefile, from the command line or
as a side effect of changing a config option.
* After applying a patch, kbuild must work out what has changed and
only rebuild the affected targets. Even if the patch changes the
dependencies or commands!
Most of the work of kbuild 2.5 is tracking all the special cases, as is
a lot of the code in kbuild 2.4 Rules.make. Any custom builder would
have to do the same amount of work and tracking, so replacing make by
another tool would not save anything. I looked at the various make
replacements like scons, but none of them were ready for the
complexities of kbuild.
On Fri, Apr 05, 2002 at 10:52:43PM +1000, Keith Owens wrote:
> On a smaller config (full config takes too long when single threaded).
>
> kbuild 2.4:
> make oldconfig dep bzImage modules 6:25
> make bzImage modules (no changes) 0:22
>
> kbuild 2.5:
> make oldconfig installable 4:45
> make installable (no changes) 0:16
How does it compare in (ahem) 32-64MB machines?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Keith Owens <[email protected]> writes:
> On a smaller config (full config takes too long when single threaded).
>
> kbuild 2.4:
> make oldconfig dep bzImage modules 6:25
> make bzImage modules (no changes) 0:22
>
> kbuild 2.5:
> make oldconfig installable 4:45
> make installable (no changes) 0:16
Hmm, can you explain the two minutes of difference ? Is the old build
that inefficient?
-Andi
On Fri, 5 Apr 2002 14:29:23 +0100,
Russell King <[email protected]> wrote:
>On Fri, Apr 05, 2002 at 10:52:43PM +1000, Keith Owens wrote:
>> On a smaller config (full config takes too long when single threaded).
>>
>> kbuild 2.4:
>> make oldconfig dep bzImage modules 6:25
>> make bzImage modules (no changes) 0:22
>>
>> kbuild 2.5:
>> make oldconfig installable 4:45
>> make installable (no changes) 0:16
>
>How does it compare in (ahem) 32-64MB machines?
You could always try it yourself, but ...
Same .config, on a Pentium III (Coppermine) 1090 Bogomips, 2.4.18 SMP
kernel booted with maxcpus=1, mem=32M.
kbuild 2.4:
make oldconfig dep bzImage modules 15:11
make bzImage modules (no changes) 0:33
kbuild 2.5:
make oldconfig installable 13:33
make installable (no changes) 0:33
Even at 32MB, kbuild 2.5 is slightly faster.
On 05 Apr 2002 16:37:12 +0200,
Andi Kleen <[email protected]> wrote:
>Keith Owens <[email protected]> writes:
>> On a smaller config (full config takes too long when single threaded).
>>
>> kbuild 2.4:
>> make oldconfig dep bzImage modules 6:25
>> make bzImage modules (no changes) 0:22
>>
>> kbuild 2.5:
>> make oldconfig installable 4:45
>> make installable (no changes) 0:16
>
>Hmm, can you explain the two minutes of difference ? Is the old build
>that inefficient?
Yes. kbuild 2.4 invokes a separate copy of make for each directory,
with significant start up overhead. Plus it runs most directories
twice, once for built in and once for modules, it was the only way to
handle separate flags for kernel and module code. Rules.make has been
trying to use make as a programming language, but it was never designed
for that.
kbuild 2.5 does a lot of work up front (in C) to build a single, global
makefile which only requires one copy of make and one pass over the
entire kernel. When the global makefile has been built and the kernel
is already up to date, make runs the global makefile with the entire
kernel dependency tree in sub second time.
BTW, all kbuild 2.5 times so far have been using the unoptimized
pre-processor programs, with all my debugging checks still turned on.
On Fri, 05 Apr 2002 21:26:08 +1000,
Keith Owens <[email protected]> wrote:
>kbuild 2.4:
> make oldconfig 0:07
> make dep 0:37 (make -j dep is unsafe on some architectures)
> make -j8 bzImage modules 14:16
> Total 15:00
> make -j8 bzImage modules 2:10 (second run, no changes, spurious rebuilds)
>
>kbuild 2.5:
> make -j8 oldconfig installable 8:51 (no make dep needed :)
> make -j8 oldconfig installable :14 (second run, no changes)
Just to avoid any confusion. kbuild 2.4 is the existing kernel build
system, as used in Marcelo's and Linus's kernels. kbuild 2.5 is the
complete rewrite of the kernel build system. Although it says 2.5,
kbuild 2.5 will run on 2.4 kernels, it was developed on 2.4.
The timings above were for exactly the same .config on the same build
machine, building a 2.4.16 kernel, using the existing and new kernel
build system. Compared to the existing build system, kbuild 2.5 is
much more robust (I found several bugs in the 2.4 rules while
developing kbuild 2.5), provides more facilities, has debugging
information, is more accurate (2.5 tracks everything, 2.4 only managed
about 80% tracking accuracy) and still manages to run 30% faster than
the existing build system.
Although kbuild 2.5 will run on 2.4 kernels, I have no plans to send
all of kbuild 2.5 to Marcelo. Changing the kernel build on a stable
kernel is a bad idea. I will be sending some kbuild 2.4 bug fixes to
Marcelo but not the rest of kbuild 2.5. I am now working on kbuild 2.5
patches for 2.4.18, 2.4.19-pre6, 2.5.7 and 2.5.8-pre1 as well as for
other architectures, see http://sourceforge.net/projects/kbuild for
updates.
Thanks to Peter Samuelson and Tom Duffy, 2.4.18 i386 patches are now
available for kbuild 2.5. Instructions at the start of each patch.
http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=83065
kbuild-2.5-core-1.bz2 (unchanged)
kbuild-2.5-common-2.4.18-1.bz2 (new)
kbuild-2.5-i386-2.4.18-1.bz2 (new)
On Sat, Apr 06, 2002 at 12:03:15PM +1000, Keith Owens wrote:
> The timings above were for exactly the same .config on the same build
> machine,
Can you provide details of this machine?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, Apr 06, 2002 at 12:03:15PM +1000, Keith Owens wrote:
> Just to avoid any confusion. kbuild 2.4 is the existing kernel build
> system, as used in Marcelo's and Linus's kernels. kbuild 2.5 is the
> complete rewrite of the kernel build system.
So that means that you have a system which does more, is more accurate,
and is faster than the system we currently use. Right? Rock on.
Has anyone integrated the kbuild stuff into a BK tree, so I could pull
from it and play with it? If not, I might have a go at it and make
a bk://kbuild.bkbits.net project.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 6 Apr 2002 17:35:39 +0100,
Russell King <[email protected]> wrote:
>On Sat, Apr 06, 2002 at 12:03:15PM +1000, Keith Owens wrote:
>> The timings above were for exactly the same .config on the same build
>> machine,
>
>Can you provide details of this machine?
It was in the original message.
http://marc.theaimsgroup.com/?l=linux-kernel&m=101800612931031&w=2
2.4.19-pre6 i386 patches are now available for kbuild 2.5.
Instructions at the start of each patch.
Kai, could you verify that the ISDN selection works as expected, both
old and new ISDN code?
http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=83065
kbuild-2.5-core-1.bz2 (unchanged)
kbuild-2.5-common-2.4.19-pre6-1.bz2 (new)
kbuild-2.5-i386-2.4.19-pre6-1.bz2 (new)
Hi,
Keith Owens wrote:
> kbuild 2.5:
> make -j8 oldconfig installable 8:51 (no make dep needed :)
> make -j8 oldconfig installable :14 (second run, no changes)
These 14 seconds (or 37 seconds on my machine) are always needed
whatever I try, e.g. "make foo/bar.o" also needs that time.
Some other problems:
"make foo/bar.[si]" doesn't work anymore.
"touch include/linux/mm.h" doesn't cause a recompile of any object.
bye, Roman
On Sun, 07 Apr 2002 16:18:12 +0200,
Roman Zippel <[email protected]> wrote:
>Keith Owens wrote:
>
>> kbuild 2.5:
>> make -j8 oldconfig installable 8:51 (no make dep needed :)
>> make -j8 oldconfig installable :14 (second run, no changes)
>
>These 14 seconds (or 37 seconds on my machine) are always needed
>whatever I try, e.g. "make foo/bar.o" also needs that time.
make NO_MAKEFILE_GEN=1 foo/bar.o. Very low overhead for quick and
dirty testing of changes, but if you want an accurate kernel build, you
have to take the overhead. kbuild 2.4 overhead for a full build when
only minor changes have been made is even worse.
>Some other problems:
>"make foo/bar.[si]" doesn't work anymore.
Hmm, that was working, I will investigate.
>"touch include/linux/mm.h" doesn't cause a recompile of any object.
I have found some cases where the timestamps are not tracked correctly
so changes to dependencies are not always detected. Fixed in
build-2.5-core-2, out tomorrow.
Hi,
Keith Owens wrote:
> >These 14 seconds (or 37 seconds on my machine) are always needed
> >whatever I try, e.g. "make foo/bar.o" also needs that time.
>
> make NO_MAKEFILE_GEN=1 foo/bar.o. Very low overhead for quick and
> dirty testing of changes, but if you want an accurate kernel build, you
> have to take the overhead. kbuild 2.4 overhead for a full build when
> only minor changes have been made is even worse.
I don't want a kernel build, I just want a single object file to be
rebuilt?!
I can understand that it takes longer, when I change a Makefile or the
config, but why has the Makefile to be rebuilt, when only a source file
changed?
bye, Roman
On Sun, 07 Apr 2002 16:51:36 +0200,
Roman Zippel <[email protected]> wrote:
>Keith Owens wrote:
>> make NO_MAKEFILE_GEN=1 foo/bar.o. Very low overhead for quick and
>> dirty testing of changes, but if you want an accurate kernel build, you
>> have to take the overhead. kbuild 2.4 overhead for a full build when
>> only minor changes have been made is even worse.
>
>I don't want a kernel build, I just want a single object file to be
>rebuilt?!
>I can understand that it takes longer, when I change a Makefile or the
>config, but why has the Makefile to be rebuilt, when only a source file
>changed?
It takes time to do all the analysis to work out what has changed and
what has been affected. You might know that you only changed one file
but kernel build and make don't know that until they have checked
everything. Changing one file or specifying a command override might
affect one file or it might affect the entire kernel.
If you know that you have only changed one source file and you have not
altered the Makefiles or the dependency chain in any way, then it
_might_ be safe to just rebuild that one file, use NO_MAKEFILE_GEN=1.
Otherwise let kbuild work out what has been affected.
Hi,
Keith Owens wrote:
> It takes time to do all the analysis to work out what has changed and
> what has been affected. You might know that you only changed one file
> but kernel build and make don't know that until they have checked
> everything. Changing one file or specifying a command override might
> affect one file or it might affect the entire kernel.
Doing that analysis once is fine. After that it should know what it has
to check if I only want foo/bar.o recompiled and that shouldn't take
that long.
> Otherwise let kbuild work out what has been affected.
That's the problem with kernel hackers, they want to know what's going
on. :)
bye, Roman
Keith Owens wrote:
>It takes time to do all the analysis to work out what has changed and
>what has been affected. You might know that you only changed one file
>but kernel build and make don't know that until they have checked
>everything. Changing one file or specifying a command override might
>affect one file or it might affect the entire kernel.
>
>If you know that you have only changed one source file and you have not
>altered the Makefiles or the dependency chain in any way, then it
>_might_ be safe to just rebuild that one file, use NO_MAKEFILE_GEN=1.
>Otherwise let kbuild work out what has been affected.
>
Humans/Hackers are really really REALLY good at making assumptions and
using assumptions that are outdated, thus leading to mistakes.
Some/many hackers like to live in there own little world and not worry
about the effect they might have on other developers. Using a
dependency maintenance tool (such as Make, Cook, ...) to automate the
build is the _ONLY_ safe way to be sure the build is correct. This
assumes that the build system itself is 100% correct :)
Regards,
Brendan Simon.
On Sun, 07 Apr 2002 16:18:12 +0200,
Roman Zippel <[email protected]> wrote:
>"touch include/linux/mm.h" doesn't cause a recompile of any object.
I have found a bug that is probably causing your problem. Can you
confirm that you are using a common source and object directory, i.e.
no separate object tree?
Hi,
On Mon, 8 Apr 2002, Keith Owens wrote:
> >"touch include/linux/mm.h" doesn't cause a recompile of any object.
>
> I have found a bug that is probably causing your problem. Can you
> confirm that you are using a common source and object directory, i.e.
> no separate object tree?
Yes, so far I only tested this.
bye, Roman
New core code for kbuild 2.5 is available in
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-core-2.bz2
Backout core-1 then apply this patch.
Changes from core-1.
Do not set KBUILD_OBJECT for objects that are linked into multiple
conglomerates, there is no unambiguous KBUILD_OBJECT value for such
objects. These objects will not be able to use module or boot
parameters in the forthcoming merge of module and boot parameter
handling.
Create object directory before copying .prepend/.append files. Fixes
Richard Chan's bug report.
make foo/bar.[si] works again. Fixes Roman Zippel bug report.
Correctly standardize relative names. Fixes Roman Zippel "touch
include/linux/mm.h" does nothing bug. Only affected builds in common
source and object mode.
Update timestamps on files generated by make as they are used. This
removes some spurious rebuilds.
Changes to the underlying database layout to reduce the mmap
footprint. This speeds up kbuild 2.5 on smaller machines.
New core, common and ia64 code for kbuild 2.5 is available in
http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=83065
Changes from core-2 to core-3.
Ensure that database records are aligned. Do not assume that keys
are aligned (all the world is not a 386).
Changes from common-2.4.18-1 to common-2.4.18-2.
Minor changes to common code to suit ia64.
New, ia64-020226-2.4.18-1.
core-3 works on ia64, it should work on other architectures that have
alignment requirements such as sparc.
Other architecture maintainers can use core-3 and common-2.4.18-2 as a
starting point for porting this release of kbuild 2.5 to their
architecture. The existing arch patches from Release 1.12 are a good
starting point, ia64 was almost unchanged from Release 1.12 to 2.0.
I have not tested any of the kbuild 2.5 code on big endian machines.
It should work as is but it would be nice to have it confirmed.
On Tue, 2002-04-09 at 06:08, Keith Owens wrote:
> Other architecture maintainers can use core-3 and common-2.4.18-2 as a
> starting point for porting this release of kbuild 2.5 to their
> architecture. The existing arch patches from Release 1.12 are a good
> starting point, ia64 was almost unchanged from Release 1.12 to 2.0.
>
> I have not tested any of the kbuild 2.5 code on big endian machines.
> It should work as is but it would be nice to have it confirmed.
Ok, with core-3, now kbuild 2.5 v2.0 works on sparc64. There was one
typo in one sparc64 Makefile.in from 1.12. Attached is the patch to fix
this.
Also attached is the full kbuild 2.0 patch for sparc64 2.4.18 tree.
--
He who receives an idea from me, receives instruction himself without
lessening mine; as he who lights his taper at mine, receives light
without darkening me. -- Thomas Jefferson
On 09 Apr 2002 12:00:55 -0700,
Thomas Duffy <[email protected]> wrote:
>Ok, with core-3, now kbuild 2.5 v2.0 works on sparc64. There was one
>typo in one sparc64 Makefile.in from 1.12. Attached is the patch to fix
>this.
>
>Also attached is the full kbuild 2.0 patch for sparc64 2.4.18 tree.
Thanks Tom. Uploaded as
http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-sparc64-2.4.18-1.bz2
I will get 2.5.8-pre2 working and upload that then wait for a couple of
days to see if any other arch maintainers have kbuild 2.5 patches.
Then it will be time for Release 2.1 which will be a candidate to go to
Linus.
New core and common code for kbuild 2.5 is available in
http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=83065
Changes from core-3 to core-4.
GNUism removal.
WISH is exposed in case your wish binary is not in /usr/bin/wish.
awk changed to $(AWK) throughout.
PP_variables added to expose headers and compiler flags that might be
different on on non-Linux build platforms.
Force the use of KBUILD_SHELL instead of relying on a working build
platform shell.
Drop back to getopt if getopt_long is not available on the build
platform, in which case only the single character command flags are
available.
Documentation updates.
*** kbuild 2.5-core-4 runs on Solaris using gcc, gmake, gawk. ***
Would any brave (or foolhardy) person like to run kbuild 2.5 under
Cygwin or other build platforms?
Changes from common-2.4.18-2 to common-2.4.18-3.
Yet more aic7xxx problems :(
Documentation updates.
Correct fencepost error in scripts/tkparse.
Changes from common-2.4.19-pre6-1 to common-2.4.19-pre6-2.
As for common-2.4.18-2 -> 3.
Updates for kbuild 2.5 at
http://sourceforge.net/project/showfiles.php?group_id=18813
I made the mistake of use the sourceforge fast release system. Turns
out it creates new releases for each file so there are multiple
'Release 2.0' headings. Ignore that, they are all part of Release 2.0.
kbuild-2.5-core-5.bz2. Changes from core-4 to core-5.
Split config immediately after make *config instead of as a side
effect of the next target. Cleaner rules, fewer special cases.
Add include/sound on include list.
New command 'select_elsewhere()'. A complete kludge to work around
the crc32.o problem in 2.5 kernels. Selection of CONFIG_CRC32 should
really be done in CML but CML1 cannot cope, so add a kbuild kludge to
overcome the incomplete CML data.
Fix a bug where cached timestamps prevented the detection of some
config changes.
kbuild-2.5-common-2.4.18-4.bz2. Changes from common-2.4.18-3 to common-2.4.18-4.
DocBook tweaks.
Add dummy dep rule for people who forget that make dep is not required.
New - support for 2.5 kernels, starting with 2.5.8-pre3. i386 only for
now, ia64 to follow.
kbuild-2.5-common-2.5.8-pre3-1.bz2.
Built from scratch, there was too much divergence between 2.4.18 and
2.5.8-pre3 Makefiles. The result was cross checked against Peter
Samuelson's patch for 2.5.6pre1, for which much thanks.
kbuild-2.5-i386-2.5.8-pre3-1.bz2
Mainly from i386-2.4.18-1, with updates for i386-2.5.8-pre3.
TODO:
Add config help to common-2.5.8-pre3-1. I could not decide where to
put the config help in 2.5 so I left it until -2.
Sync common-2.4.19-pre* with common-2.4.18-<n>. Will be done when
next 2.4.19-pre* kernel comes out.
Add 2.4.18-ia64-020410 support. Already supports 2.4.18-ia64-020226.
Add 2.5.8-pre3-ia64-020411 support.
Wait for other arch maintainers to roll patches against kernel 2.5.
Create Release 2.1 with the latest version of each kernel and arch branch.
See how stable release 2.1 is then contact Linus.
On Sun, 14 Apr 2002 23:23:16 +1000,
Keith Owens <[email protected]> wrote:
>Updates for kbuild 2.5 at
>http://sourceforge.net/project/showfiles.php?group_id=18813
>kbuild-2.5-i386-2.5.8-pre3-1.bz2
i386-2.5.8-pre3-1 was missing this bit, against i386-2.5.8-pre3-1.
Apply this patch or use kbuild-2.5-i386-2.5.8-pre3-2.bz2.
diff -urN 2.5.8-pre3-kbuild-2.5/arch/i386/kernel/Makefile.in 2.5.8-pre3-kbuild-2.5-save/arch/i386/kernel/Makefile.in
--- 2.5.8-pre3-kbuild-2.5/arch/i386/kernel/Makefile.in Tue Apr 16 11:09:25 2002
+++ 2.5.8-pre3-kbuild-2.5-save/arch/i386/kernel/Makefile.in Sun Apr 14 11:45:28 2002
@@ -27,5 +27,11 @@
# uses_asm_offsets(entry.o)
+# "Unterminated character constants", due to mismatched ' in comments
+extra_aflags(entry.o -traditional)
extra_aflags(head.o -traditional)
extra_aflags(trampoline.o -traditional)
+
+extra_cflags(acpi.o $(fixme_acpi_includes))
+extra_cflags(pci-irq.o $(fixme_acpi_includes))
+extra_cflags(setup.o $(fixme_acpi_includes))