[llvm-bugs] [Bug 48505] New: PCH use over-aggressively validates input header mtime

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48505

            Bug ID: 48505
           Summary: PCH use over-aggressively validates input header mtime
           Product: clang
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: daniel.johnston at intel.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Problem:

Build system has sporadic build failures with errors similar to this:

fatal error: file '/usr/include/linux/stddef.h' has been modified since the
precompiled header '<path_to_pch_file>' was built: mtime changed
note: please rebuild precompiled header '<path_to_pch_file>'

In my case, this occurs when Ubuntu decides to update a package that includes
the /usr/include/linux/stddef.h file automatically due to a security fix. 
However, since the OS package being deployed was built before the last PCH file
build, most build systems don't retrigger a PCH file build.  When using the PCH
(due to other build dependency changes), clang will fail because the mtime was
updated (even if the mtime is older than the PCH file).

I'm guessing I could use -fno-validate-pch to work around this issue, however,
I can't seem to find sufficient documentation of that option to determine if
this would work or what other (desirable) checks would be disabled.

In short:

build systems typically only check that the mtime of dependent files are not
newer than the target file

clang fails when dependent file mtime was updated since pch creation, but is
not newer than the actual pch file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201214/2a23e298/attachment.html>