Re: Did someone try to boot 2.4.16 on a 386 ? [SOLVED]

[willy tarreau]

> 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