[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#238257: race condition on timestamps for cmi/mli files

On Tue, 2004-03-16 at 01:57, Remi Vanicat wrote:
> What is strange here is that OCamlMakefile use explicit depend over
> some system library. It should not even bother. He may even not know
> that there exist a gl.cmi (and gl.mli) file. How do you use the
> OCamlMakefile ?
Yes.  The problem is that it uses ocamldep too strictly.

On Tue, 2004-03-16 at 04:55, Remi Vanicat wrote: 
> precisely this Makefile do Work :
This is essentially what I was using.  To be sure, I copied your
example and the same thing occurs.  You should be able to replicate
it by doing
 $ sudo touch /usr/lib/ocaml/3.07/lablgl/gl.mli
 $ make
So the problem is that dpkg might unpack some ocaml package and start
copying the files while crossing over a 1 second boundry.
Since gl.cm* is copied before gl.mli, its possible that the gl.mli
will get a later timestamp.  Thus when ocamldep reports that
gears.ml depends on gl.mli and gl.mli is older than gl.cmi, it will
try and recompile them, resulting in an error.  Precisely:
 ocamlc -c -I +labltk -I +lablgl -I +labltk -I +lablgl 
 I/O error: /usr/lib/ocaml/3.07/lablgl/gl.cmi: Permission denied

On Tue, 2004-03-16 at 07:49, Stefano Zacchiroli wrote:
> Mike, could you please check if the bug applies also to the latest
> OCamlMakefile version available here: 
> http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html
This behavior is still present in this version.  Again, its not so
much a bug in ocamlmakefile(this is what is should be doing), but 
rather a fluke in the timing that dpkg unpacked that particular

One possible solution would be to pipe the output of ocamldep through
'grep -v /usr/lib/ocaml/3.07' to prevent any system libraries from being

Mike Furr <mfurr@debian.org>
1024D/124B26F3 5B9F 587F BC5C D823 50CE  4DB0 ED93 CA29 124B 26F3

Reply to: