Asked by Scott Warren on 4 April 2013 at 21:08

This can be caused by incorrect timestamps on *.rtree and *.str files. Each .rtree file should be newer than its corresponding .str file. This is true in the tarball as distributed, but you may have manually disturbed this relationship during or after extraction. To fix the problem, re-extract from the tarball. Do not use tar’s “–touch” option because it discards archived timestamps.

Why the error occurs: if an .rtree file is not newer than its corresponding .str file, make tries to recreate the .rtree file by running sglri on the .str file. Since this is unexpected when building from a tarball, an sglri executable may not yet be available. The result is a “no such file” error on sglri. See the discussion of baseline development and bootstrapping at http://tinyurl.com/ccm4qrw for more information.

Answered by Scott Warren on 4 April 2013 at 21:09

Be careful if you try to fix this problem by “touching” the .rtree files instead of re-extracting. Just touching .rtree files may break other timestamp relationships which must hold for the build to succeed. Sometimes an .rtree file has a corresponding .c file, in which case the .c file must also be newer than the .rtree file for the build to succeed. It’s best just to re-extract the entire tarball.

Answered by Scott Warren on 4 April 2013 at 21:13