On 17/06/2018 15:15, Jean-Marc Pigeon wrote: > Hello, > > Weird problem within GCC and I don't know if it is "mine", "lfs" > or "upstream". > > - the problem: > I am successful to compile cmake. > AND (everything almost equal) > I am not successful to compile cmake: > BUILD/cmake-3.11.2/Utilities/cmlibuv/src/unix/timer.c -o uv-src-unix-timer.c.o > In file included from > /home/jmp/rpmbuild/BUILD/cmake-3.11.2/Source/cmQtAutoGeneratorMocUic.h:9, > from > /home/jmp/rpmbuild/BUILD/cmake-3.11.2/Source/cmcmd.cxx:10: > /home/jmp/rpmbuild/BUILD/cmake-3.11.2/Source/cmQtAutoGenerator.h:58:10: error: > 'mutex' in namespace 'std' does not name a type > std::mutex Mutex_; >
The error is in cmQtAutoGeneratorMocUic.h... Is Qt installed? > - The context: > I am trying to qualify LFS as a production system. > One criteria of a production system is to be able to regenerate > itself over 3 generations, packages being build in a > a random order and in a highly parallel sequences. > Previously, this was proved no problem with LFS-8.1 and LFS-8.2, > trying to do the same with SVN-20180612. > > Chapter III. Building the LFS System > 6. Installing Basic System Software > make a gcc 8.1.0 which CAN compile a working cmake. > > This gcc is the first generation, and was created with > the bootstrap GCC (generation 0, chapter 5. Constructing a Temporary System), > the second generation GCC (compiled with first generation GCC) > is able to compile over 200 packages (vim, coreutils, httpd, etc..) > excepted cmake (I guess it is a gcc++ anomaly) > > - Debugging > The default is proved to be coming from > /usr/include/c++/8.1.0 > there is files present in gcc second generation (example stdc++.h) > missing from the first. Really looks like the infamous "include-fixed" problem. When some packages are installed on the system, GCC may decide their include files are "wrong", and fix them. Of course the first time GCC is built in chapter 6, there are (almost) no packages on the system, and nothing is fixed. The second time you build gcc (using the first one), it may happen that packages "to be fixed" (according to GCC) are now present, so that they are fixed... Whether this has some relationship with your problem, I am not sure. But it is at least one way to explain a different behavior at the second GCC compilation. > [...] BTW, sorry for not updating GCC in BLFS. I have had no time to work on LFS lately, and now my LFS system lags behind recent (up to 2 month old) changes, and I have to rebuild one... Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
