Unreproducible errors during compilation

[acheron2]

I've been using media-video/swfmill with these ebuilds for years on my old computer. New versions compiled without problems, but some people reported compilation errors.

After moving to a new multicore computer I started getting errors too. Odd things are:

1. Compiling the sources in my home directory worked.
2. Compiling the sources with the command

[acheron2]

Another reason that makes me think it's a race condition, is this. All errors were in *.cpp files generated by xsltproc. All errors were either about unmatched bracket or undeclared variable. When I checked the file, where the error occurred, all brackets were matched and there was no variable with such name, but instead a variable starting with it — no "Trac", but "Trace". As if the compiler read the incomplete source file.

If this is true, how should I change the makefile to avoid it?

[Hu]

The most likely cause for the behavior you are seeing is that someone wrote a rule of the form:

[acheron2]

Thanks.

In Makefile xsltproc is called only once:

[Hu]

Yes, the change you describe should work. You can test whether the problem is solved by checking how many times xsltproc is run during compilation. It should run only once.

[acheron2]

[Hu]

Given the rule you showed above, I believe using -j1 was the reason the failures ceased. For your second question, it depends on other factors. If a single Make is managing the entire process, then I think the order of events would be correct. Make should inventory all of the goals, determine which objects it needs to satisfy those, then determine which sources it needs to satisfy those objects. It should then begin generating those sources, but notice that those sources require the target .sources.generated, so it will build that first. It will then run the null rules defined for the individual sources, then move to compiling. I think the failure mode you describe can occur only if Make delays dependency resolution. You could get into problems with recursive make, since a recursive make may not have all the rules present in a single process.

You could test this by replacing the xsltproc rule with one which writes an ill-formed gSWFWriteXML.cpp, sleeps long enough that other jobs ought to finish, then replaces the ill-formed gSWFWriteXML.cpp with a valid one, and exits successfully. Then run a parallel build and see if it defers the compilations until the sleep terminates.

[acheron2]

Thanks, I'll try that. Probably next weekend