-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
release 3.0.
kbuild-2.5-core-15
Changes from core-14.
Replace mdbm with kbuild specific database engine to increase
performance.
Remove CML2 support, Dominik Brodowski, Keith Owens.
Remove the restriction on symlinked sources and targets. Aegis
users should be able to use kbuild 2.5 now.
kbuild-2.5-common-2.5.19-1.
Changes from common-2.5.15-4.
Upgrade to kernel 2.5.19.
kbuild-2.5-i386-2.5.19-1.
Changes from i386-2.5.15-2.
Upgrade to kernel 2.5.19.
Larry McVoy provided the mdbm database engine from BitKeeper for use in
kbuild 2.5 release 2.0-2.4, and was extremely helpful in answering my
questions about mdbm. Unfortunately some of the processing required by
kbuild 2.5 did not fit well with the mdbm model. Since an application
specific database will always outperform a generic database, I took
advantage of knowledge about the kbuild data and wrote an application
specific database engine.
This is not a criticism of mdbm - it is a good generic database engine.
I could squeeze a few more seconds out of the build time by using
application specific knowledge.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE8+tXYi4UHNye0ZOoRAp+5AJ9evi07/7D1+xHRRnxA8xdpeqY3hgCeMcrH
kgNAIKaGHE1Fy8BKByBZqXs=
=EamL
-----END PGP SIGNATURE-----
Why was CML2 support removed?
Hayden A. James
Computer Engineering
Stevens Institute of Technology
http://attila.stevens-tech.edu/~hjames/
On Mon, 3 Jun 2002 00:06:16 -0400,
Hayden James <[email protected]> wrote:
>Why was CML2 support removed?
ESR has dropped off the list. CML2 and kbuild 2.5 are completely
independent and having the two in the same patch was getting messy.
The config rules in kbuild 2.5 are clean, support for other variants of
CML can be added at any time.
Hi,
On Mon, 3 Jun 2002, Hayden James wrote:
> Why was CML2 support removed?
It's prettily explained at
<URL:http://www.mail-archive.com/kbuild-devel%40lists.sourceforge.net/msg01469.html>
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Mon, 03 Jun 2002 12:35:05 +1000,
Keith Owens <[email protected]> wrote:
>Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
>http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
>release 3.0.
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.
On Sun, 2002-06-02 at 19:35, Keith Owens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> release 3.0.
>
> kbuild-2.5-core-15
> Changes from core-14.
>
> Replace mdbm with kbuild specific database engine to increase
> performance.
>
> Remove CML2 support, Dominik Brodowski, Keith Owens.
>
> Remove the restriction on symlinked sources and targets. Aegis
> users should be able to use kbuild 2.5 now.
I get this error now on sparc64:
tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
phase 1 (find all inputs)
make: *** [phase1] Error 139
tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
phase 1 (find all inputs)
pp_makefile1: Attempt to fetch invalid key s(0x73)-9473
make: *** [phase1] Error 134
more verbose (PP_MAKEFILE1_FLAGS=-v) output:
...
Generating global Makefile
phase 1 (find all inputs)
pp_makefile1 verbose 1
scan_trees 0 /build2/tduffy/linux_kbuild/
make: *** [phase1] Error 139
-tduffy
Hi,
On 3 Jun 2002, Thomas Duffy wrote:
> I get this error now on sparc64:
>
> tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
> Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
> phase 1 (find all inputs)
> make: *** [phase1] Error 139
>
> tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
> Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
> phase 1 (find all inputs)
> pp_makefile1: Attempt to fetch invalid key s(0x73)-9473
> make: *** [phase1] Error 134
>
> more verbose (PP_MAKEFILE1_FLAGS=-v) output:
>
> ...
> Generating global Makefile
> phase 1 (find all inputs)
> pp_makefile1 verbose 1
> scan_trees 0 /build2/tduffy/linux_kbuild/
> make: *** [phase1] Error 139
>
>
> -tduffy
Did you apply the sparc64 patch? Yet it's there.
You might even try the upcoming -ct1
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Mon, 2002-06-03 at 12:31, Thunder from the hill wrote:
> Did you apply the sparc64 patch? Yet it's there.
yes.
this is failing in the db code, my guess.
> You might even try the upcoming -ct1
ok, I will give it a go, but I think this is a problem in core-15
(kbuild v3.0)
-tduffy
Hi,
On 3 Jun 2002, Thomas Duffy wrote:
> > Did you apply the sparc64 patch? Yet it's there.
>
> this is failing in the db code, my guess.
Gee, you're right!
> > You might even try the upcoming -ct1
>
> ok, I will give it a go, but I think this is a problem in core-15
> (kbuild v3.0)
Could you please try the core-14 beforehand? (Yes, beat me, Keith, but if
it works, we'll have a stepping stone!)
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Mon, 2002-06-03 at 13:06, Thunder from the hill wrote:
> Could you please try the core-14 beforehand? (Yes, beat me, Keith, but if
> it works, we'll have a stepping stone!)
<= core-14 works fine...
-tduffy
On 03 Jun 2002 12:22:18 -0700,
Thomas Duffy <[email protected]> wrote:
>I get this error now on sparc64:
>
>tduffy@curie:/build2/tduffy/linux_kbuild$ make -f Makefile-2.5 oldconfig
>Using ARCH='sparc64' AS='as' LD='ld' CC='sparc64-linux-gcc' CPP='sparc64-linux-gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
>Generating global Makefile
> phase 1 (find all inputs)
>make: *** [phase1] Error 139
Index: 18.85/scripts/pp_db.c
--- 18.85/scripts/pp_db.c Fri, 31 May 2002 17:20:09 +1000 kaos (linux-2.4/T/f/42_pp_db.c 1.17 644)
+++ 18.85(w)/scripts/pp_db.c Tue, 04 Jun 2002 10:17:10 +1000 kaos (linux-2.4/T/f/42_pp_db.c 1.17 644)
@@ -305,7 +305,7 @@ ppdb_free_space(PPDB * db, int size)
}
oldmap = db->header;
ppdb_close(db);
- if (munmap(db->header, oldsize)) {
+ if (munmap(oldmap, oldsize)) {
fprintf(stderr, "%s: munmap(%s) failed: %m\n", program,
ppdb_name);
abort();
The previous coding error will have corrupted the database so rm .tmp_db_main.
On Mon, 2002-06-03 at 17:19, Keith Owens wrote:
> Index: 18.85/scripts/pp_db.c
> --- 18.85/scripts/pp_db.c Fri, 31 May 2002 17:20:09 +1000 kaos (linux-2.4/T/f/42_pp_db.c 1.17 644)
> +++ 18.85(w)/scripts/pp_db.c Tue, 04 Jun 2002 10:17:10 +1000 kaos (linux-2.4/T/f/42_pp_db.c 1.17 644)
> @@ -305,7 +305,7 @@ ppdb_free_space(PPDB * db, int size)
> }
> oldmap = db->header;
> ppdb_close(db);
> - if (munmap(db->header, oldsize)) {
> + if (munmap(oldmap, oldsize)) {
> fprintf(stderr, "%s: munmap(%s) failed: %m\n", program,
> ppdb_name);
> abort();
>
> The previous coding error will have corrupted the database so rm .tmp_db_main.
awesome. that fixes the problem. thanks.
-tduffy
On Mon, 03 Jun 2002 12:35:05 +1000,
Keith Owens <[email protected]> wrote:
>Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
>http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
>release 3.0.
New files:
kbuild-2.5-core-16
Changes from core-15.
Override some command line variables to ensure that they are changed.
Replace -nostdinc with Russell King's version.
Print full filename in warning message.
Correct lock filename.
Correct unmap old db (sparc64 SEGV).
Tweak dirty flag checking.
kbuild-2.5-common-2.5.20-2.
Changes from common-2.5.20-1.
Correct drivers/acpi/Makefile.in, Arnd Bergmann.
kbuild-2.5-s390-2.5.20-1.
kbuild-2.5-s390x-2.5.20-1.
Arnd Bergmann.
Got this trying to compile 2.5.20 with Debian's gcc 2.95.4.
Why it took the system-wide zlib.h?
$ make -f Makefile-2.5 fs/isofs/compress.o KBUILD_QUIET=
...
scripts/pp_makefile5 --type=CC --target=fs/isofs/compress.o --src=fs/isofs/compress.c --srctree=999 --flags='-Ifs/isofs -I- -D__KERNEL__ -Iinclude/ -I.tmp_include/src_000/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -fomit-frame-pointer -march=i686 -nostdinc -iwithprefix include -DKBUILD_OBJECT=isofs -DKBUILD_BASENAME=compress -DMODULE '
In file included from /export/home/riesen-pc0/riesen/compile/v2.5/fs/isofs/compress.c:38:
include/linux/zlib.h:34: zconf.h: No such file or directory
On Tue, Jun 04, 2002 at 02:53:28PM +1000, Keith Owens wrote:
> On Mon, 03 Jun 2002 12:35:05 +1000,
> Keith Owens <[email protected]> wrote:
> >Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> >http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> >release 3.0.
>
> New files:
>
> kbuild-2.5-core-16
> Changes from core-15.
>
> Override some command line variables to ensure that they are changed.
>
> Replace -nostdinc with Russell King's version.
>
> Print full filename in warning message.
>
> Correct lock filename.
>
> Correct unmap old db (sparc64 SEGV).
>
> Tweak dirty flag checking.
>
> kbuild-2.5-common-2.5.20-2.
> Changes from common-2.5.20-1.
>
> Correct drivers/acpi/Makefile.in, Arnd Bergmann.
>
> kbuild-2.5-s390-2.5.20-1.
> kbuild-2.5-s390x-2.5.20-1.
>
> Arnd Bergmann.
>
> -
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 drivers/pci/pci-driver.c to be registered. Both is called at
subsys_initcall level, but in kbuild-2.5 the arch specific parts are
run first. The symtom is a 'BUG in device.h:75' from get_bus() early in
bootup.
The brute force workaround for this problem is to put
link_subdir(drivers/pci) before link_subdir(arch/$ARCH) in the top level
Makefile.in.
I could not find out from the kbuild-2.4 files how or why it works there, but
I don't think relying on the link order here is a good idea anyway, so it
would best be fixed in the pci code itself.
Arnd <><
On Tue, 4 Jun 2002 11:16:46 +0200,
Alex Riesen <[email protected]> wrote:
>Got this trying to compile 2.5.20 with Debian's gcc 2.95.4.
>Why it took the system-wide zlib.h?
>In file included from /export/home/riesen-pc0/riesen/compile/v2.5/fs/isofs/compress.c:38:
>include/linux/zlib.h:34: zconf.h: No such file or directory
In order to do separate source and object correctly, kbuild 2.5
enforces the rule that #include "" comes from the local directory,
#include <> comes from the include path. include/linux/zlib.h
incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>,
breaking the rules.
This was not detected by common-2.5.20-1 because the nostdinc check was
incomplete, common-2.5.20-2 does nostdinc correctly. I avoid changing
the source code for kbuild 2.5, instead I workaround these incorrect
includes by adding extra_cflags() with FIXME comments to correct the
code later. I will do a common-2.5.20-3 to workaround zlib.h, in the
meantime try this quick and dirty fix
--- 2.5.20-pristine/include/linux/zlib.h Mon Apr 15 05:18:43 2002
+++ 2.5.20-kbuild-2.5/include/linux/zlib.h Tue Jun 4 11:03:05 2002
@@ -31,7 +31,7 @@
#ifndef _ZLIB_H
#define _ZLIB_H
-#include "zconf.h"
+#include <linux/zconf.h>
#ifdef __cplusplus
extern "C" {
Keith Owens scripsit:
> In order to do separate source and object correctly, kbuild 2.5
> enforces the rule that #include "" comes from the local directory,
> #include <> comes from the include path. include/linux/zlib.h
> incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>,
> breaking the rules.
This is not the standard gcc behavior, however; quoted-includes
can come from the include path, although the current directory
is searched first. The purpose of <>-includes is to suppress
searching the current directory.
--
John Cowan <[email protected]> http://www.reutershealth.com
I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
On Tue, 4 Jun 2002 22:25:20 -0400 (EDT),
John Cowan <[email protected]> wrote:
>Keith Owens scripsit:
>
>> In order to do separate source and object correctly, kbuild 2.5
>> enforces the rule that #include "" comes from the local directory,
>> #include <> comes from the include path. include/linux/zlib.h
>> incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>,
>> breaking the rules.
>
>This is not the standard gcc behavior, however; quoted-includes
>can come from the include path, although the current directory
>is searched first. The purpose of <>-includes is to suppress
>searching the current directory.
What gcc allows and what the kernel uses as a coding style are two
different things. Almost all of the kernel uses <> for global files
and "" for local files, this is the only sane way of coding for a large
project. However there are some exceptions where the wrong form has
been used.
The wrong form causes problems for separate source and object
directories. It also causes problems when you do not compile in the
same directory that does not contain the source, i.e. when you do a
global make instead of recursive make. kbuild 2.5 has identified all
of the problem includes. I avoided changing the source, instead I
added extra include paths as a temporary workaround, with FIXME
comments for later clean up. I noticed that some people have already
used the kbuild 2.5 FIXME comments to clean up their code.
On Wed, Jun 05, 2002 at 08:55:35AM +1000, Keith Owens wrote:
> On Tue, 4 Jun 2002 11:16:46 +0200,
> Alex Riesen <[email protected]> wrote:
> >Got this trying to compile 2.5.20 with Debian's gcc 2.95.4.
> >Why it took the system-wide zlib.h?
> >In file included from /export/home/riesen-pc0/riesen/compile/v2.5/fs/isofs/compress.c:38:
> >include/linux/zlib.h:34: zconf.h: No such file or directory
>
> In order to do separate source and object correctly, kbuild 2.5
> enforces the rule that #include "" comes from the local directory,
> #include <> comes from the include path. include/linux/zlib.h
> incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>,
> breaking the rules.
>
> This was not detected by common-2.5.20-1 because the nostdinc check was
> incomplete, common-2.5.20-2 does nostdinc correctly. I avoid changing
> the source code for kbuild 2.5, instead I workaround these incorrect
> includes by adding extra_cflags() with FIXME comments to correct the
> code later. I will do a common-2.5.20-3 to workaround zlib.h, in the
> meantime try this quick and dirty fix
Sorry for delay. The patch fixed things, indeed.
And i personally prefer the way you did it here
much more to any workarounds.
> --- 2.5.20-pristine/include/linux/zlib.h Mon Apr 15 05:18:43 2002
> +++ 2.5.20-kbuild-2.5/include/linux/zlib.h Tue Jun 4 11:03:05 2002
> @@ -31,7 +31,7 @@
> #ifndef _ZLIB_H
> #define _ZLIB_H
>
> -#include "zconf.h"
> +#include <linux/zconf.h>
>
> #ifdef __cplusplus
> extern "C" {
>
On Mon, 03 Jun 2002 12:35:05 +1000,
Keith Owens <[email protected]> wrote:
>Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
>http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
>release 3.0.
New files:
kbuild-2.5-core-17
kbuild-2.5-common-2.5.20-3
kbuild-2.5-i386-2.5.20-2
Synchronize link order with 2.5.20. Between 2.5.15 and 2.5.19
there were several changes to the kernel link order that look
dubious to me. Originally kbuild 2.5 for 2.5.20 preserved the
original order from 2.5.15, but I have since decided to follow the
2.5.20 link order, even if it looks broken in places.
common-2.5.20-3 also adds workarounds for include/linux/zlib.h.
On Tue, Jun 04, 2002 at 10:25:20PM -0400, John Cowan wrote:
> Keith Owens scripsit:
> > In order to do separate source and object correctly, kbuild 2.5
> > enforces the rule that #include "" comes from the local directory,
> > #include <> comes from the include path. include/linux/zlib.h
> > incorrectly does #include "zconf.h" instead of #include <linux/zconf.h>,
> > breaking the rules.
> This is not the standard gcc behavior, however; quoted-includes
> can come from the include path, although the current directory
> is searched first. The purpose of <>-includes is to suppress
> searching the current directory.
It raises the question 'who not always use #include "..."'?
In the case of a tool that generates dependencies for a source file,
the difference is sensibility.
In other cases, it is just common sense.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
On Wed, 05 Jun 2002 23:53:43 +1000,
Keith Owens <[email protected]> wrote:
>Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
>http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
>release 3.0.
New files:
kbuild-2.5-core-18
Change from core-17.
Add a missing case for dependency standardization.
kbuild-2.5-common-2.4.18-8
kbuild-2.5-i386-2.4.18-3
Synchronize link order method with 2.5.20, so both 2.4 and 2.5
versions of kbuild 2.5 use the same process.
kbuild-2.5-common-2.4.19-pre10-1
kbuild-2.5-i386-2.4.19-pre10-1
Upgrade to 2.4.19-pre10. Also has new link order method.
On Wed, 05 Jun 2002 23:53:43 +1000,
Keith Owens <[email protected]> wrote:
>Release 3.0 of kernel build for kernel 2.5 (kbuild 2.5) is available.
>http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
>release 3.0.
New files:
kbuild-2.5-core-19
Change from core-18.
Change allno/allyes/allmod to all*config.
Replace $([<^@][DF]) with $(dir/notdir).
Do a dummy write to the database to workaround a kernel bug on
timestamps of mmaped files.
kbuild-2.5-i386-2.4.18-4
kbuild-2.5-i386-2.4.19-pre10-2
Backport CC/CC_real fix from 2.5.
kbuild-2.5-common-2.5.21-1
kbuild-2.5-i386-2.5.21-1
Upgrade to 2.5.21.
More arch patches for 2.5.21 to follow.
On Wed, 2002-06-12 at 06:54, Keith Owens wrote:
> New files:
>
> kbuild-2.5-core-19
> kbuild-2.5-i386-2.4.18-4
> kbuild-2.5-i386-2.4.19-pre10-2
> kbuild-2.5-common-2.5.21-1
> kbuild-2.5-i386-2.5.21-1
hrm. I don't see any of these on the sourceforge site...
Are they really missing, or am I an idiot?
-tduffy
On 12 Jun 2002 13:55:44 -0700,
Thomas Duffy <[email protected]> wrote:
>On Wed, 2002-06-12 at 06:54, Keith Owens wrote:
>
>> New files:
>>
>> kbuild-2.5-core-19
>
>> kbuild-2.5-i386-2.4.18-4
>> kbuild-2.5-i386-2.4.19-pre10-2
>
>> kbuild-2.5-common-2.5.21-1
>> kbuild-2.5-i386-2.5.21-1
>
>hrm. I don't see any of these on the sourceforge site...
I got side tracked and did not complete the upload. They are there
now.