Hi again !
Just to say that I finally solved my problem. It came
from a wrong vmlinux.lds that had been modified by a
TUX patch applied to an earlier kernel sharing a hard
link with this one. Although I think an unlink before
a regeneration of this file would have been better,
I'll check around to see if there are other parts
which risk to modify a file on disk without previously
unlink it.
Now 2.4.16 works correctly on this 8MB 386.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
On Sat, 1 Dec 2001 01:42:47 +0100 (CET),
=?iso-8859-1?q?willy=20tarreau?= <[email protected]> wrote:
>Just to say that I finally solved my problem. It came
>from a wrong vmlinux.lds that had been modified by a
>TUX patch applied to an earlier kernel sharing a hard
>link with this one. Although I think an unlink before
>a regeneration of this file would have been better,
A perfect example of why having the same tree for source and generated
files and using cp -al is a bad idea. cp -al picks up both source and
objects and you have to hope that anything that is overwritten is hard
link safe (I can tell you now that it is not). kbuild 2.5 allows
multiple builds from the same source tree into separate object trees
with different configs and is safe.
>I'll check around to see if there are other parts
>which risk to modify a file on disk without previously
>unlink it.
Any Makefile that does "some_command > target_file" or runs a utility
that does open(O_TRUNC) instead of unlink(), open(O_EXCL).
BTW, cp -al of a pristine source tree to multiple source trees followed
by multiple compiles in parallel is not safe either. make dep relies
on changing time stamps for include files, because the include files
are hard linked, a change in one compile affects the other trees, with
undefined results. Also fixed in kbuild 2.5.
> A perfect example of why having the same tree for
> source and generated files and using cp -al is a
> bad idea. cp -al picks up both source and
> objects and you have to hope that anything that is
> overwritten is hard link safe (I can tell you now
> that it is not).
well, at least I only duplicate clean sources before
applying a patch. So there is absolutely no shared
object. It's just that when I try patches, I have
about 20 source trees and it's cool to have the
ability to navigate through versions without having
to store 3 GB. Moreover, diff -urN is much faster
this way. But it true that this is a "use at your own
risk".
> kbuild 2.5 allows multiple builds from the same
> source tree into separate object trees
> with different configs and is safe.
Interesting, I think I'll definitely take a look at
it.
> >I'll check around to see if there are other parts
> >which risk to modify a file on disk without
> previously
> >unlink it.
>
> Any Makefile that does "some_command > target_file"
> or runs a utility that does open(O_TRUNC) instead
> of unlink(), open(O_EXCL).
there was such an example in the past with aicasm.
Anyway, I think that any tool, script or Makefile
that modifies the source tree and which results in
a diff between the two trees after a "make distclean"
is at risk because it can induce diffs between some
files that can't always apply to another clean tree.
> BTW, cp -al of a pristine source tree to multiple
> source trees followed by multiple compiles in
> parallel is not safe either. make dep relies on
> changing time stamps for include files, because
> the include files are hard linked, a change in
> one compile affects the other trees, with
> undefined results. Also fixed in kbuild 2.5.
Never needed to do that yet.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
On Sat, 1 Dec 2001 10:11:40 +0100 (CET),
=?iso-8859-1?q?willy=20tarreau?= <[email protected]> wrote:
>Keith Owens wrote
>Anyway, I think that any tool, script or Makefile
>that modifies the source tree and which results in
>a diff between the two trees after a "make distclean"
>is at risk because it can induce diffs between some
>files that can't always apply to another clean tree.
ABSOLUTELY AGREE!!!!! (Is that too many exclamation marks?)
But try telling people that shipping files then overwriting them is a
bad idea.
>> BTW, cp -al of a pristine source tree to multiple
>> source trees followed by multiple compiles in
>> parallel is not safe either.
>
>Never needed to do that yet.
The moment you use cp -al on a kernel source tree, you are running the
risk of time stamp problems.
cp -al pristine tree1
cp -al pristine tree2
cd tree1
make *config bzImage
cd tree2
make *config bzImage
The make in tree1 and tree2 touches the time stamps on included files.
Because most include files are hard linked, it changes the time stamps
on all three trees, including the pristine source. Even if you never
compile in tree1 and tree2 at the same time, when you switch back and
forth between trees you will get semi-random time stamp changes.
Normally the unwanted time stamp updates only forces spurious
recompiles, but I believe that there are some sequences that create an
incomplete kernel build.
> But try telling people that shipping files then
> overwriting them is a bad idea.
if a file is to be modified, then it ought to be
copied at make time, deleted at clean time, and
only its copy should be used. Anyway, by definition,
a modified file is not a source anymore.
> The moment you use cp -al on a kernel source tree,
> you are running the risk of time stamp problems.
>
> cp -al pristine tree1
> cp -al pristine tree2
> cd tree1
> make *config bzImage
> cd tree2
> make *config bzImage
>
> The make in tree1 and tree2 touches the time stamps
> on included files. Because most include files are
> hard linked, it changes the time stamps on all three
> trees, including the pristine source. Even if you
> never compile in tree1 and tree2 at the same time,
> when you switch back and forth between trees you
> will get semi-random time stamp changes.
so a recursive touch before a make in such a tree
should be safer ?
> Normally the unwanted time stamp updates only forces
> spurious recompiles, but I believe that there are
> some sequences that create an incomplete kernel
> build.
Although I can't swear I never encountered this
problem, I can tell that I already had some
interrogations about strangely compiled kernels
which led me to repatch against a clean tree.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
On Sat, 1 Dec 2001 10:47:33 +0100 (CET),
=?iso-8859-1?q?willy=20tarreau?= <[email protected]> wrote:
>Keith Owens wrote
>> Even if you
>> never compile in tree1 and tree2 at the same time,
>> when you switch back and forth between trees you
>> will get semi-random time stamp changes.
>
>so a recursive touch before a make in such a tree
>should be safer ?
Yes, as long as you only touch the source files, not any objects that
have already been created.
As I mentioned before, all these problems are solved in kbuild 2.5.
http://sourceforge.net/projects/kbuild/, Package kbuild-2.5. I just
putting the 1.10 release together, against kernel 2.4.16.