On Fri, 21 Jul 2017 08:46:35 +0200 Pierre Labastie <pierre.labas...@neuf.fr> wrote:
> I'd say it is enough to remove the "build" directory. But if you keep > the "build" directory, i'd say you are calling for trouble. Pierre, You are right, after all, being able to keep the source tree pristine is main incentive to use a build directory. > However, GCC source is written in C++, so GCC needs libstdc++. . . > The compiler *code* does not use threads (because it was generated by > GCC pass 1, which has no thread capabilities, but the compiler *can* > generate code using threads. That mostly clears it up for me. Although I would say it as "The gcc *executable* does not use threads ...". (FWIW, several times I caught myself saying it the exact same way you did in what I wrote below.) So, gcc pass 1 is linked against the host's libstdc++; and the purpose of pass 2 is simply so that the new binutils and gcc are linked against the new glibc and libstdc++. And at the end of the GCC stage 2 build, a new gcc and a libstdc++ are created and installed; and when this new libstdc++ is created and installed as part of the gcc build process, it will overwrite the (nonthreaded) one installed in section 5.8 and then both gcc and libstdc++ will support threads (internally, as well as externally as compiled output). So, even though gcc pass 2 was *compiled* against a libstdc++ that did not support threads (as that was built with gcc pass1), it still will be able to use threads when it (gcc pass 2) is actually run, right? Doesn't this have ramifications for upgrading gcc? For example, instead of merely compiling and installing a new gcc, we should first upgrade libstdc++ by itself as in section 5.8 (but with the \usr --prefix and maybe even with thread support) and then compile and install the new gcc. Otherwise, the new gcc will remain linked against the old libstdc++ even though the gcc build also installs a new libstdc++, right? It seems to me that libstdc++ should now be separated from gcc just like glibc is. > That's why libstdcc++ compilation for pass1 is deferred to after glibc > build. But note that the just built glibc *has* all the libraries for > thread support. It is only GCC pass1 that does not have the ability to > generate code supporting threads, so that --disable-threads needs to > be passed to libstdc++ pass 1. OK, but this suggests there is a mistake in the LFS book. Specifically in the libstdc++ step: http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html " --disable-libstdcxx-threads Since we have not yet built the C threads library, the C++ one cannot be built either. " This is wrong, right? As you note above the reason we have to disable threads for libstdc++ is because gcc (pass 1) cannot yet output C++ executables or libraries that utilize threads. glibc (either from the host system or that installed in section 5.7), however, *does* already have thread support. From the GCC configure manual: https://gcc.gnu.org/install/configure.html "--enable-threads Specify that the target supports threads. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++." So, only libstdc++ or other C++/Objective-C code that is to be compiled by gcc is affected by a gcc configured with --disable-threads. The option does not affect gcc's ability with regard to compiling threaded C code. Cheers and thanks, Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
