Hi,
we recently migrated our build system from CMake 3.6.3 to 3.20.2. We build on Windows with VS and on Linux with various cross compilers and mostly the migration went smoothly. However one of our Linux builds using gcc 4.9.4 is crashing with an internal compiler error since the migration. To make things worse it does that randomly roughly in 1 out of three runs. Always on the same source file (needless to say that it hasn’t changed 
)
When I compared the parameters passed to the compiler I only saw one difference when running CMake 3.20:
-MD -MT Tests/NAME_OF_THE_TARGET/CMakeFiles/NAME_OF_THE_TARGET.dir/NAME_OF_THE_SOURCE_FILE.cpp.o -MF CMakeFiles/NAME_OF_THE_TARGET.dir/NAME_OF_THE_SOURCE_FILE.cpp.o.d -o CMakeFiles/NAME_OF_THE_TARGET.dir/NAME_OF_THE_SOURCE_FILE.cpp.o
This is new with the latest CMake version and from the release notes it seems to be related to the following statement in version 3.20
Makefile Generators, for some toolchains, now use the compiler to extract implicit dependencies while compiling source files.
What I see then is this:
x86_64-unknown-linux-gnu-g++: internal compiler error: Killed (program cc1plus)
make[2]: Leaving directory '/tmp/BUILD_DIR'
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [Tests/NAME_OF_THE_TARGET/CMakeFiles/NAME_OF_THE_TARGET.dir/build.make:76: Tests/NAME_OF_THE_TARGET/CMakeFiles/NAME_OF_THE_TARGET.dir/NAME_OF_THE_SOURCE_FILE.cpp.o] Error 4
make[1]: *** [CMakeFiles/Makefile2:4833: Tests/NAME_OF_THE_TARGET/CMakeFiles/NAME_OF_THE_TARGET.dir/all] Error 2
What might be important is that we call ‘make’ with the ‘-j’ switch so multiple instances run in parallel. Our idea was that maybe the access to this dependecy file is somewhat not thread-safe but we might be completely wrong there.
Does that ring a bell anywhere?
Regards,
Stefan
Dependencies management is thread-safe. You can use freely option -j.
Unfortunately, may-be, you are confronted to a compiler bug related to this feature. Can you try a full cycle (configuration/generation/compilation) by specifying -DCMAKE_DEPENDS_USE_COMPILER=OFF on cmake command line to deactivate this feature?
Alternatively, can you use a more recent compiler version?
Hi Marc,
I tried your suggestion (-DCMAKE_DEPENDS_USE_COMPILER=OFF) and so far it looks promising! I will observe this for another week before giving final feedback but wanted to say thank you first! A more recent compiler unfortunately is not an option since we are shipping an SDK which has to operate on some pretty old platforms.
Hi Marc,
after some more analysis and testing I think it is safe to say, that CMake(or the update of CMake) has nothing to do with the effect. Meanwhile I have removed the -DCMAKE_DEPENDS_USE_COMPILER=OFF switch again. The reason for this nasty effect is an updated operating system on our side. Even though we use a cross-build chain and effectively check out the compiler as part of the sources on the target machine this new system seems to crash our cross-compiler (g++) from time to time. Since I removed this particular build agent from the list of build agents building our code everything went back to normal again. If someone encounters similar effects: It is an ubuntu 20.04 and we have other trouble with it as well: Sometimes our unit test crash with this message: Inconsistency detected by ld.so: ../elf/dl-tls.c: 481: _dl_allocate_tls_init: Assertion listp->slotinfo[cnt].gen <= GL(dl_tls_generation)’ failed!`. This points towards a bug inside glibc: Bug #1863162 “Inconsistency detected by ld.so: dl-tls.c: 493: _d...” : Bugs : glibc package : Ubuntu.
Anyway: By now I am certain CMake has nothing to do with this! Thanks for your help and sorry for the trouble!
Regards,
Stefan
Thanks for your feedback.