Hello Bruce (and list) On 06/17/2018 07:11 PM, Bruce Dubbs wrote:
[....]
If I had time, what I would do first is save all the headers in /usr/include and /usr/libexec. Then after reinstalling gcc look for include-fixed again and compare the original and the 'fixed' headers to see what gcc thinks changed. BTW, I have had students run into this before and was able to hack their system s/include-fixed/include/. That seemed to work but the testing and additional packages were minimal. Perhaps when I get some time, I'll try installing gcc with only fortran,go,objc,obj-c++ to see if that raises the problem. After all there is really no need to reinstall the same version of c and c++ after the base LFS install. -- Bruce
First, a little bit of disagreement "no need to reinstal...." :-} LFS project, present itself as a learning tool, I agree and really believe LFS team is doing a very very good job at it. But, we can't say, Please do not recompile GCC as "mileage will vary", if so; why not check with the horoscope if today recompile will generate good code. random code generation for a compiler is not something to be teach. :-} So we have 3 options: - I am not analyzing correctly cmake failure to compile and my finding can't be reproduce (I am wrong in some way). - GCC configuration (as provided by LFS) make no identical binaries, it depend on its compilation context. - Problem stand in cmake itself, but this is not detected by compiler in chapter-06 context. Let summarize problem so fare. 2 gcc-8.1.0 compilers. one is generated by http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html lets name it gcc-lfs the second one is generated by gcc-lfs recompiling gcc sources. lets name it gcc-blfs. gcc-lfs can compile cmake gcc-blfs can NOT compile cmake Problem is proved (100%) to be related to contents of /usr/include/c++/8.1.0 (and only to this contents) I have made a diff, gcc-blfs come with 23 "extra" files as extracted by diff. Here they are: > usr/include/c++/8.1.0/bits/gthr-single.h > usr/include/c++/8.1.0/bits/c++config.h > usr/include/c++/8.1.0/bits/c++locale.h > usr/include/c++/8.1.0/bits/stdtr1c++.h > usr/include/c++/8.1.0/bits/c++io.h > usr/include/c++/8.1.0/bits/cxxabi_tweaks.h > usr/include/c++/8.1.0/bits/basic_file.h > usr/include/c++/8.1.0/bits/gthr.h > usr/include/c++/8.1.0/bits/ctype_base.h > usr/include/c++/8.1.0/bits/os_defines.h > usr/include/c++/8.1.0/bits/cpu_defines.h > usr/include/c++/8.1.0/bits/gthr-default.h > usr/include/c++/8.1.0/bits/c++allocator.h > usr/include/c++/8.1.0/bits/gthr-posix.h > usr/include/c++/8.1.0/bits/time_members.h > usr/include/c++/8.1.0/bits/error_constants.h > usr/include/c++/8.1.0/bits/stdc++.h > usr/include/c++/8.1.0/bits/atomic_word.h > usr/include/c++/8.1.0/bits/ctype_inline.h > usr/include/c++/8.1.0/bits/messages_members.h > usr/include/c++/8.1.0/bits/extc++.h > usr/include/c++/8.1.0/bits/opt_random.h > usr/include/c++/8.1.0/ext/opt_random.h Again, those files are not present with gcc-lfs. Unfortunately I am not fluent enough in C++ to see the common ground to all those included files (and why they show up in gcc-blfs???) In the mid time I have explored the include-mixed possibility by adding (copied from LFS-7.1 GCC) sed -i \ -e "s@\./fixinc\.sh@-c true@" \ gcc/Makefile.in to GCC compiling sequence (before ./configure). It was a wild guess, may be a stupidity not really addressing include-mixed potential problem as you see it. anyway the cmake problem still show up. Hoping provided data can help us about this weird problem. Many thanks for your contribution. -- Jean-Marc
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
