Issue #214 resolved

PCH with gmake and -j2 or larger

Daniel Seifert
created an issue

Using premake 4.4 beta 5, creating a gmake project and compiling using make -jX with X>1, precompiled header support is not working quite right. The precompiled header is generated along with the source code, so the source files will abort with an error that they do not find the precompiled header.

Example for reproduction attached, run it with

premake gmake make -j4

(tested with premake 4.4 beta 5 binary for Linux)

Comments (23)

  1. Daniel Seifert reporter

    The same happens, btw, with the nightly from December 15.

    > ./bin/release/premake5 gmake
    > make -j4
    ==== Building Example (release_native) ====
    Creating obj
    cc1plus: fatal error: obj/default.h: No such file or directory
    compilation terminated.
    cc1plus: error: one or more PCH files were found, but they were invalidcc1plus: error: one or more PCH files were found, but they were invalid
    cc1plus: error: use -Winvalid-pch for more information
    cc1plus: fatal error: obj/default.h: No such file or directory

    Running make again will compile succesfully, as the PCH file was now created correctly.

  2. Johannes Spohr

    With the most recent pull request, I´m seeing sporadic failures on Linux (gcc) and Mac (clang), with 4 different machines:

    > make -j4 -k config=retailstatic_x64
    ... (a few projects being built successfully)
    ==== Building scape_scene (retailstatic_x64) ====
    Creating ../../../obj/linux64/gmake/x64/retailstatic/scape_scene
    ../../../source/modules/../../source/runtime/scape/scene/scapescenepch.h:1:0: fatal error: can't create precompiled header ../../../obj/linux64/gmake/x64/retailstatic/scape_scene/scapescenepch.h.gch: No such file or directory
    compilation terminated.
    Preprocessed source stored into /tmp/ccPdb1uf.out file, please attach this to your bugreport.
    make[1]: *** [../../../obj/linux64/gmake/x64/retailstatic/scape_scene/scapescenepch.h.gch] Error 1
    make[1]: Target `all' not remade because of errors.
    make: *** [scape_scene] Error 2

    This happens once or twice a day on our CI server, most often on clean builds. The .h.gch file is not created. The makefiles generated with an older build of premake5 (May 2014) didn´t show this issue. Could this be an I/O conflict on the GCH file? I don´t know if this is related to the change in the pull request, but for now I will have to disable PCH for gmake targets.

  3. Johannes Spohr

    Thanks for reopening the issue. I know this is a difficult thing to fix, because it´s not easily reproducible. If you require more information, please let me know. I´ll try to revert change from the pull request, and see if that resolves the errors.

  4. Johannes Spohr

    OK, I´ll leave the builds running without -j for a few days, and report back. However, last night on of the Linux builds failed again, with a slightly confusing error message:

    ../../../source/runtime/scape/render/backend/renderbackend.cpp:1:0: fatal error: opening dependency file ../../../obj/linux/gmake/x32/retailstatic/scape_render/renderbackend.d: No such file or directory
    compilation terminated.
    The bug is not reproducible, so it is likely a hardware or OS problem.
    make[1]: *** [../../../obj/linux/gmake/x32/retailstatic/scape_render/renderbackend.o] Error 1

    I don´t know how GCC is able to deduce that this is a hardware or OS problem. As I mentioned earlier, there are 4 machines running these builds every night, and I guess that it`s unlikely all of them are broken. On a Mac, it failed with this error:

    ==== Building scape_renderreflectors (retailstatic_x64) ====
    Creating ../../../obj/macosx64/gmake/x64/retailstatic/scape_renderreflectors
    error: unable to open output file '../../../obj/macosx64/gmake/x64/retailstatic/scape_renderreflectors/renderreflectors.o': 'Error opening output file '../../../obj/macosx64/gmake/x64/retailstatic/scape_renderreflectors/renderreflectors.o': No such file or directory'
    1 error generated.
    scape_renderreflectors.make:154: recipe for target '../../../obj/macosx64/gmake/x64/retailstatic/scape_renderreflectors/renderreflectors.o' failed
    make[1]: *** [../../../obj/macosx64/gmake/x64/retailstatic/scape_renderreflectors/renderreflectors.o] Error 1
    make[1]: Target 'all' not remade because of errors.
    Makefile:568: recipe for target 'scape_renderreflectors' failed

    To make things even more confusing, this specific error seems to be limited to that machine only. The other Mac is building fine since PCHs were switched off. So yeah, maybe I have a defective Mac on my hands, but the PCH issue was observable on all 4 machines. Out of 34 builds each night, an average of 1 or 2 are failing. Each build contains about a thousand C and C++ source files.

  5. Johannes Spohr

    Since running builds without -j over a week ago, the errors disappeared on all build machines. So I guess the failures are a result of make running on multiple threads, and synchronization errors due to some dependency missing in the makefiles. I´m not a makefile guy at all, so I really don´t know what to do to resolve this. If I can give you any more details, please just ask.

  6. Johannes Spohr

    Just a heads up, I´m going to revert the patch for our premake build, so I can use make -j4 again. I don´t need makefile concurrency that much, because our solution contains almost 200 projects, and building those in parallel is enough to keep a quad core busy.

  7. Jason Perkins

    I'm not sure what to do with this one. Is anyone working successfully with the current code? I'm thinking I should mark it as resolved, and open a new issue if the trouble Johannes reported appears for anyone else.

  8. Johannes Spohr

    I got the strange "bug is not reproducible" error on Linux again last night. So this is definitely not related to the change from the pull request. But it is something that never happened with our older build of premake5, either. PCH are still disabled, so I guess my issue is indeed a different case of failure, and this one can be closed. I still haven`t ruled out a hardware defect on my end, but right now I´m considering going back to the premake build that worked. Perhaps I´m able to diff the makefiles against each other, but right now I don´t have time to go into that.

  9. Log in to comment