On 06/17/2018 01:31 PM, Bruce Dubbs wrote: [snip]
Forget about RPM, (RPM is compiled under LFS-8.2), lets say it a convenient way to compile things and lets assume/say, I follow the very exact LFS-way to compile each package. So RPM, or no RPM, is not meaningful regarding the trouble itself.Can you summarize what you are doing again. The best I can tell is that you are doing:1. LFS 2, Build GCC a 2nd time (using LFS, not BLFS, procedures) 3. Build GCC a 3rd time (using LFS, not BLFS, procedures) 4. Build cmake -- Bruce1. LFS up to end of chapter 6 (lets say up to vim) at that stage if I compile cmake, compilation and code generated is OKLets call that LFS1.2) recompile all components (using RPM, with %build and %install same as describe in LFS). -> Including GCC too. Do a fresh install in another chroot directory. the new install (obviously) is discarding /tools as the bootstrap procedure being fully completed.Well I am not able to look at that. I've never bothered to look at rpm internals in order to use it to do a build.
However, the way I read your comments is that you are not in a chroot for the 2nd build. Or that you are in LFS1's chroot from the original host.
As requested in chapter-06, I recompile GCC-8.1.0 with chroot /lfs Later on, I re-install LFS (+ some packages), lets say a palatable BLFS under another chroot (no /tools anymore) and recompile gcc-8.1.0
3) rebuilding again same RPM packages... All packages are still compiled OK but cmake. cmake compilation return error because of /usr/include/cc++/8.1.0 content (contents generated by gcc compilation in step 2). So far my understanding... LFS procedure are/seems_to_be correct but LFS result can't be used to self duplicate itself...We use a previous LFS build to build the next version all the time. But we do go through the Chapter 5 build as a part of that procedure. We always end up building gcc-x.y.z with the gcc-x.y.z from Chapter 5 pass 2.
Agreed, I am compiling the SVN-20180612 using an host running under BLFS-8.2. CAUTION: we can't be satisfied about compiling and keeping gcc-8.1.0 from chape-06. "./configure" can/will introduce compilation context and it is exactly, my guess, the root of cmake current problem. My advice: Adjust chapter06 to recompile once again GCC after VIM, to make sure we have a stable GCC before going to BLFS. Bruce?, My advice/request to do a little experimentation. 1) Do you have a BLF-SVN-20180612, (fully populated, many libraries)? with chapt-06 GCC-8.1.0? 2) recompile cmake (no trouble, right?) 3) could you recompile/re-install (within that BLFS) a brand new gcc-8.1.0 over it. 4) could your recompile cmake and confirm (or not) my finding. Thanks.
so there is problem... my guess, so far, within GCC ./configure parameters... I am working trying to figure out what GCC ./configure find as different within the 2 context.You might want to capture ls -Rl before and after you detect your problem and try to see if there are files that are different.
As reported there is (many) differences within /usr/include/c++/8.1.0 It was proved (experimentally) the problem stand within that directory.stdc++.h as supplementary file trigger my attention (but there is other and I didn't prove removing /usr/include/c++/8.1.0/bits/stdc++.h clear the trouble, could be more than one file).
From my side (so fare) the chapter-06 SVN-20180612, gcc-8.1.0 config log report ;-----------------------------------------------------------------------------configure:5008: checking whether g++ accepts -static-libstdc++ -static-libgcc configure:5025: g++ -o conftest -g -O2 -static-libstdc++ -static-libgcc confte
st.cpp >&5
/tools-jmp/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/bin
/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
configure:5025: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| #if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
| #error -static-libstdc++ not implemented
| #endif
| int main() {}
;----------------------------------------------------------------------
BLF-2018-06-15 config log report
;----------------------------------------------------------------------
5008: checking whether g++ accepts -static-libstdc++ -static-libgcc
configure:5025: g++ -o conftest -g -O2 -static-libstdc++
-static-libgcc conftest.cpp >&5
configure:5025: $? = 0 configure:5026: result: yes ;---------------------------------------------------------------------- Unfortunately, I am not fluent enough in "gcc/g++" to know (for now, but still trying to track origin) what package trigger thestatic-libstdc++ "yes" result in gcc compilation, which later on, crash the cmake compilation...
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
