0004991: ocaml{c,opt} may truncate and recreate a .cmi, leading to (rare) failures of make -j

Notes
(0005257) frisch (developer) 2010-03-04 20:20	OMake's approach is to force ocamlopt to use the .cmi file produced by ocamlc. This is done by creatin a dependency on this .cmi file (when then .mli file does not exist) for the ocamlopt rule, and to use "-intf-suffix .cmi" to let ocamlopt believe that the interface does exist. That said, we also observe random and rare cases of "corrupted compiled interface" during parallel builds under Windows. Maybe there is something wrong with the approach above, or it's just Windows that decides to do random errors.

(0005258) letouzey (reporter) 2010-03-04 20:39	:-) Thanks Alain, I actually though of this -intf-suffix, but I was so sure this kind of trick would simply not work that I didn't even take the time to try. Guess what, I'll go and test that now. And indeed, I've also made .cmx depend on .cmi... Concerning the windows build, I played recently with mingw32 cross-compilation (more precisely, the debianisation of the work of R. Jones for fedora). And It's so cool to be able to build .exe (even coqide) for a decent dev platform. Best, Pierre

(0005260) letouzey (reporter) 2010-03-08 11:25	Ok, after testing Alain's tip I can confirm that "-intf-suffix .cmi" is exactly what I was looking for. Thanks. I think this bug report can be closed. My only remaining suggestion would be to document more properly this trick: as I told in my first comment above, after reading man pages for ocaml{c,opt}, I was (wrongly) conviced that files indicated via -intf-suffix would have to be _source_ interface file, while they actually are only checked for existence and never looked into. Best regards, Pierre

(0005272) doligez (manager) 2010-03-25 11:25	The way I see it, the best solution is to have a .mli for each .ml file. (For rather obscure reasons, it also makes the GC very slightly more efficient.) The next best thing would be to make the compiler output the compiled interface to a temporary file, then move it atomically to the .cmi (although I'm not sure if that's possible under Windows).

(0005302) frisch (developer) 2010-04-06 23:14	Damien: what's wrong with the -intf-suffix solution?

(0005324) xleroy (administrator) 2010-04-18 14:31	Re: atomic file rename: it's unclear this can be done under Windows. The rename() function from the C standard library, interfaced in Caml as Sys.rename, fails if the destination file exists. The MoveFileEx Win32 system call can be cajoled into replacing an existing file, but it is not specified that this happens atomically. (Google "MoveFileEx atomic".) Re: opening the .cmi twice: the second open-for-reading is done to compute the MD5 digest of the data just written. OCaml's I/O channels don't support opening for reading and writing at the same time. Re: the -intf-suffix trick: I'm happy that it provides a workaround. Still, I have the feeling that something is slightly wrong here, so I'll leave this PR as a feature wish.

(0005372) doligez (manager) 2010-04-26 13:21	I have no reason to believe there is currently something wrong with the -intf-suffix trick, but it still feels like a hack.

Issue History
Date Modified	Username	Field	Change
2010-03-04 19:36	letouzey	New Issue
2010-03-04 20:20	frisch	Note Added: 0005257
2010-03-04 20:39	letouzey	Note Added: 0005258
2010-03-08 11:25	letouzey	Note Added: 0005260
2010-03-25 11:25	doligez	Note Added: 0005272
2010-04-06 23:14	frisch	Note Added: 0005302
2010-04-18 14:31	xleroy	Note Added: 0005324
2010-04-18 14:31	xleroy	Severity	minor => feature
2010-04-18 14:31	xleroy	Status	new => acknowledged
2010-04-18 14:31	xleroy	Description Updated
2010-04-26 13:21	doligez	Note Added: 0005372

Relationships