Le 23/02/2020 à 09:20, Tadeus Prastowo via lfs-dev a écrit : > On Sun, Feb 23, 2020 at 7:58 AM Pierre Labastie via lfs-dev > <lfs-dev@lists.linuxfromscratch.org> wrote: >> >> Le 23/02/2020 à 07:21, Pierre Labastie via lfs-dev a écrit : >>> Le 23/02/2020 à 00:33, Tadeus Prastowo via lfs-dev a écrit : >>>> On Sat, Feb 22, 2020 at 11:10 PM Pierre Labastie via lfs-dev >>>> <lfs-dev@lists.linuxfromscratch.org> wrote: >>>>> >>>>> Le 22/02/2020 à 18:33, Tadeus Prastowo via lfs-dev a écrit : >>>>>> On Sat, Feb 22, 2020 at 6:17 PM Douglas R. Reno via lfs-dev >>>>>> <lfs-dev@lists.linuxfromscratch.org> wrote: >>>>>>> If we're going off an 'svn blame', it was done at r10226. That would've >>>>>>> been GCC-4.8.0: >>>>>>> >>>>>>> http://wiki.linuxfromscratch.org/lfs/browser/trunk/BOOK/chapter05/libstdc%2B%2B.xml?annotate=blame >>>>>> >>>>>> Thank you very much for the pointer. I see that the change was >>>>>> committed by Pierre. >>>>> >>>>> I'm almost sure the option was needed at the time. gcc-4.8.0 was the >>>>> first gcc >>>>> to be written in C++, hence the need for adding C++ support in pass1. >>>> >>>> I think the `--disable-libstdcxx-threads' option was not needed even >>>> at that time. In other words, I am sure that the option was included >>>> in the book without a failing build to support the use of the option >>>> (perhaps the option was included just because its name includes the >>>> word `threads'). >>> >>> I'm sure I included that because the build was failing. But I remember I've >>> been working with svn versions of gcc before 4.8 was released. So it is >>> possible I have not tested that it was still needed for 4.8. > > Even with the SVN version, I think the build failed not because of > lacking the option. I have checked the GCC changelog for the option, > and the sole reason the option was added is to avoid a __potential__ > program crash when Solaris executables compiled in a newer Solaris are > run in an older Solaris (see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52189 for the details). > The potential program crash, however, virtually cannot happen when > following the LFS book because who would stop after compiling the > libstdc++ just to use an older Solaris version to obtain the second > pass GCC? > > In other words, the description of the option given in the LFS book > about some C library or libgcc not being compiled with a thread > support is just wrong. >
Because upstream have added an option for a reason does not mean that it is the only reason for using it. Upstream does not support the way we do thing in LFS, so they may have never had the same problem as I have had. But I can swear that at some point, the build could not be done without this option. Also on svn versions before 4.8, I had to construct the directory layout of a complete build of gcc when building libstdc++ (that is something like creating build/<target>/libstdc++ and working from there). That requirement was removed at some point before releasing 4.8. Note that svn gcc changes several times a day, and sometimes may break completely, so my tests were done without following the updates. But I agree with you this is old history, and that the option should be removed. Not just now though: have you tested on several machines and distros? (me neither yet). Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
