On 06/17/2018 11:18 AM, Jean-Marc Pigeon wrote:
Hello Bruce,
On 06/17/2018 10:57 AM, Bruce Dubbs wrote:
[snip]
[snip]
error: 'mutex' in namespace 'std' does not name a type
std::mutex Mutex_;
I have just started a new build. I will check this out early.
Caution, gcc from chapter 6, will compile cmake A_OK.
[snip]
Only g++ seems in trouble.
I noticed BLFS-2018-06-15 is still using/compiling GCC-7.3.0
is this by purpose???
No. The editor that usually does that has not been available for a
while.
Am I missing something obvious?
Is someone in this list able to duplicate my finding?
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
-- Bruce
1. LFS up to end of chapter 6 (lets say up to vim)
at that stage if I compile cmake, compilation and
code generated is OK
Lets 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.
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.
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.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
