none
Compiler / PCH File Format Question

    Question

  • I’m currently writing a distributed build system, which spreads C++ compilation across multiple machines on a network. I’ve made a lot of progress, but have the following current problem.

     

    Let’s say:

    • The first build step is to build a PCH file, which is built on machine 'A'.
    • Machine B is then going to compile a regular CPP file, which uses the PCH file from A. Immediately after the compiler starts reading the PCH file, it bails with the following message:

    ".\HelloWorld.cpp(4) : fatal error C1859: 'Debug\HelloWorld.pch' unexpected precompiled header error, simply rerunning the compiler might fix this problem"

     

    • This error is entirely my ‘fault’, due to trying to use a PCH from another machine, but that's what I'm trying to get to work.
    • Looking at the binary difference between PCH files built on machines A and B, I see that they are very similar, though have some differences.
    • I suspect that the error is a result of the four bytes from bytes 102..105 in the PCH file differing when comparing PCH files built with the two machines. (Numbering the first byte in the file is byte 0).
    • It seems that bytes 102 and 103 are machine specific, and that the second two are seemingly random (vary between compiles)

     

    Can someone let me know what these four bytes are for, and how CL picks the values for them?

     

    An example answer might be something like: The first two bytes are the OS version, which come from GetOSVersion() in Kernel32.dll, and the second two bytes are the current time in seconds since windows booted, coming from 'GetTimeSinceBoot()' in Kernel32.dll.

     

    This would help me immensely. I feel that this PCH problem is the last major technical hurdle I have remaining.

     

    Thank you very much for any help!

     

    (Edit - I'm using Visual Studio 2005)

    Friday, February 22, 2008 1:52 AM

Answers

  • I suspect that no one will be able to tell you what those 4 bytes are.  Using a PCH file from machine A on machine B is simply not supported.

     

    The PCH file is basically a heap-dump from the compiler front-end.  As such, even very tiny differences in the machine configurations can affect the content, and efforts to move PCH files between machines are likely doomed to failure.

     

    Just rebuild the PCH file on each machine, and make sure that you're not putting much of anything beyond Windows SDK, ATL, WTL, MFC headers in the PCH file.  Odds are that your own code pales in comparison to the 500K or more lines of header files from the SDK/MFC/ATL, so putting your own headers into the PCH isn't buying you anything in build time but is forcing you to rebuild the PCH file more often than you would otherwise.

     

    If you only put platform includes in the PCH file, your build probably doesn't need to rebuild it except when it's missing.

     

    Friday, February 22, 2008 9:05 PM
    Moderator
  • I don't know specifically how that error is generated, but I suspect that it results from a failure to allocate the exact same heap pages on the machine consuming the PCH file as were used on the machine that generated the PCH file.  Anything that injects DLLs into processes, such as AV or monitoring software could cause such a failure by making some range of virtual address space that was available on the creating machine unavailable on the consuming machine.  Differences in platform DLLs (e.g. Windows Hotfix level, version, edition, etc) could have the same effect.

     

    Monday, February 25, 2008 7:16 PM
    Moderator

All replies

  • I suspect that no one will be able to tell you what those 4 bytes are.  Using a PCH file from machine A on machine B is simply not supported.

     

    The PCH file is basically a heap-dump from the compiler front-end.  As such, even very tiny differences in the machine configurations can affect the content, and efforts to move PCH files between machines are likely doomed to failure.

     

    Just rebuild the PCH file on each machine, and make sure that you're not putting much of anything beyond Windows SDK, ATL, WTL, MFC headers in the PCH file.  Odds are that your own code pales in comparison to the 500K or more lines of header files from the SDK/MFC/ATL, so putting your own headers into the PCH isn't buying you anything in build time but is forcing you to rebuild the PCH file more often than you would otherwise.

     

    If you only put platform includes in the PCH file, your build probably doesn't need to rebuild it except when it's missing.

     

    Friday, February 22, 2008 9:05 PM
    Moderator
  • Thanks very much for the suggestion, I hadn't thought of doing it that way. I've done some testing and think that the multiple PCH route may work for me.

     

    I'm still curious what kind of error results in

    "fatal error C1859: 'Debug\HelloWorld.pch' unexpected precompiled header error, simply rerunning the compiler might fix this problem".

    Do you know if this is a specific error, or just a big try/catch around a large body of code?

     

    Thanks again very much!

     

    Monday, February 25, 2008 5:54 PM
  • I don't know specifically how that error is generated, but I suspect that it results from a failure to allocate the exact same heap pages on the machine consuming the PCH file as were used on the machine that generated the PCH file.  Anything that injects DLLs into processes, such as AV or monitoring software could cause such a failure by making some range of virtual address space that was available on the creating machine unavailable on the consuming machine.  Differences in platform DLLs (e.g. Windows Hotfix level, version, edition, etc) could have the same effect.

     

    Monday, February 25, 2008 7:16 PM
    Moderator
  • Interestingly I just hit this error. I get it even for a newly created Win32 console app with MFC support. Clean/Rebuild sometimes fixes it. 
    http://blog.voidnish.com
    Wednesday, March 18, 2009 6:03 PM
    Moderator
  • I just got this error after migrating my Visual Studio C++ project to a brand new Windows 7 machine. It compiled perfectly on my old Vista machine. I installed Visual Studio 2008 Professional on the new Windows 7 machine, and when I try to rebuild and recompile my C++ project, I get the following error:

    fatal error C1859: 'Debug\RoboMiner.pch' unexpected precompiled header error, simply rerunning the compiler might fix this problem.

    Rerunning the comiler does not fix it.

    I tried deleting the .pch files (debug and release).  After doing that, it sometimes will compile one or the other (debug or release) but then when I try to compile the one that did not get compiled, I get the error again.

    It is a simple MFC DLL project with only a few additional functions in it
    .
    Any suggestions?

    Thanks,

    Jerry
    Sunday, October 25, 2009 7:31 PM
  • OK. I believe I have the problem fixed. Here is what I did....

    1. I installed Visual Studio 2010 Ultimate Beta 2 and built a new project in there, added my C++ code snippets, and got my code to compile in 2010.

    2. I totally deleted the project from the Visual Studio 2008 folder.

    3. I went back in to Visual Studio 2008, and created the project new again....added my code snippets, and got it to compile in 2008. It has compiled several times without error, so I think I got it fixed. There may be a problem with simply using the old Visual Studio 2008 project that was created in windows Vista and then trying to compile it in windows 7. That is my suspicion. Either that, or something magical happened when I installed the 2010 Beta ;-)

    Thanks,

    Jerry

     
    Monday, October 26, 2009 12:02 AM
  • No. I take my last post back. After successfully compiling in debug mode, and then in release, I left it for a while. I just reopened Visual Studio 2008 and set it back to debug and tried to rebuild, and got the same error:

    fatal error C1859: 'Debug\RoboMiner.pch' unexpected precompiled header error, simply rerunning the compiler might fix this problem

    This is crazy. I had made no changes to my project at all.

    Jerry

    Monday, October 26, 2009 2:03 AM
  • OK. I got it fixed. I put a comment in the stdafx.h file. That caused the precompiled header file to recompile when I rebuilt the solution. I haven't had the problem since.

    Jerry
    • Proposed as answer by e1v Friday, February 04, 2011 10:34 AM
    Tuesday, October 27, 2009 11:34 PM
  • I built the project in both release and debug mode.  Started seeing the same error for all my projects while building.
    The only work-around, you wont believe this, was to reboot the machine !!!

    This is ridiculous, but I am serious 

    ~Prasad
    Tuesday, March 02, 2010 3:30 PM
  • I had the same error for the first time today.

     

    I did copy a project from one machine to another, but I never copy the debug folder or even any pre-compiled stuff, or even the *.ncb file.

    Only the source files.

     

    Oddly, adding a comment to stdafx.h fixed it...

     

    Don't know why this would fix it, since the pch didn't even exist (that is, it was never copied from other machine).

    Tuesday, July 06, 2010 2:07 PM
  • I think I have the answer. Rather than rebootiong the machine which is very drastic. The problem on my end seemed to be related to something being left over from a previous build type. In my case I have built 32-bit target platform and then when I try to build 64-bit target, I always get this error. Doing a Clean, Rebuild all did not resolve the problem, but what I realized was that I was doing a "Clean" on the 64-bit target, so I switched back to 32-bit platform, did a "Clean" which should delete all left over .pch files and then switched back to 64-bit and it built perfectly fine. I presume this would be the same problem between Debug and Release builds. i.e. switch back to the previous build type and do a "Clean" then switch to the other build and "Build". This looks like a bug in Visual Studio. I do not work for or speak for Microsoft.
    • Edited by Youssef Monday, September 20, 2010 12:45 PM correct typo
    Monday, September 20, 2010 11:54 AM
  • I built the project in both release and debug mode.  Started seeing the same error for all my projects while building.
    The only work-around, you wont believe this, was to reboot the machine !!!

    This is ridiculous, but I am serious 

    ~Prasad
    Cleaned everything, deleted my intermediate and output directories and still got this error.  Then I rebooted and problem solved.  Thanks for this suggestion because it never would have occurred to me that rebooting might fix something like this.  And yes, it is ridiculous.
    Thursday, March 10, 2011 6:11 PM
  • What comment did you add in stdafx.h file to recompile PCH file on project/solution rebuild?

    Niranjan 

    Tuesday, October 11, 2011 10:59 AM
  • Please start a new thread to ask a new question.  It doesn't look like you're asking a question related to the original thread other than a connection to PCH files.
    -cd Mark the best replies as answers!
    Tuesday, October 11, 2011 6:55 PM
    Moderator