Changes between Version 37 and Version 38 of Building/Troubleshooting


Ignore:
Timestamp:
May 20, 2013 12:27:34 AM (11 months ago)
Author:
kazu-yamamoto
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Building/Troubleshooting

    v37 v38  
    2626This can also happen (although we don't know precisely why) if you modify something in a built tree, and then re-run `make`. In this case the error is just overly conservative, and restarting is the right workaround. 
    2727 
    28 It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads ({{{make -j}}}) or a memory-backed file system ({{{mfs}}}, {{{tmpfs}}}) (see #7592). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer).  You can change this granularity by adjusting the value of the {{{vfs.timestamp_precision}}} sysctl(3) variable (`sudo -w vfs.timestamp_precision=1`). 
     28It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads ({{{make -j}}}) or a memory-backed file system ({{{mfs}}}, {{{tmpfs}}}) (see #7592). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer).  You can change this granularity by adjusting the value of the {{{vfs.timestamp_precision}}} sysctl(3) variable (`sudo sysctl -w vfs.timestamp_precision=1`). 
    2929 
    3030If you encounter this without touching any files after typing 'make', then it's probably a bug in the build system. The `make -d` output will be useful in tracking it down, but depending on when it happens there might be a lot of it!