Bug #27

Precompiled header on GCC based platform with wrong dependencies

Added by Steven Craft over 9 years ago. Updated over 9 years ago.

Status:ResolvedStart date:08/03/2010
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


I have an example of:

  • myfile.cpp
  • stdafx.h
  • system.h

myfile.cpp uses stdafx.h as a precompiled header, and stdafx.h #includes system.h. If after the first full rebuild, I modify/touch system.h, when I hit build again, it rebuilds myfile.cpp, but it doesn't NOT recreate the precompiled header (stdafx.h -> stdafx.h.gch). To get the precompiled header to build I have to do a clean followed by another build.


#1 Updated by Steven Craft over 9 years ago

I have put together a test case for this:


It is targeted at PS3, but I believe it should happen for any GCC based platform (it happens for me both on PS3 and Wii).


#2 Updated by Steven Craft over 9 years ago

Also, I should point out, precompiled headers do correctly get regenerated on Win32-VC builds, and I wonder if the root problem behind this is that Win32-VC creates the PCH by building stdafx.cpp, so when I touch something stdafx.cpp is dependent on (system.h), it triggers stdafx.cpp to rebuild, which regenerates the PCH, which keeps everything in sync. On GCC based platforms, stdafx.cpp is not what causes the precompiled header to be created, but it builds stdafx.cpp anyway:

1>------ Build started: Project: precompiled_header_deps, Configuration: Ps3-Sony-Gcc Debug Win32 ------
1>Performing Makefile project actions
1>* found 24 target(s)...
* updating 7 target(s)...
1>@ C.C++

1>@ C.Link patience...

I'm not sure what the fix is for this, but I think this somewhat narrows it down.


#3 Updated by Joshua Jensen over 9 years ago

  • Status changed from New to Resolved

Is this fixed now? I think it is. Let's close the bug if it isn't reproducible with latest.

Also available in: Atom PDF