Le 14/03/2020 à 10:44, Pierre Labastie via lfs-dev a écrit : > Le 14/03/2020 à 09:56, Kevin Buckley via lfs-dev a écrit : >> I note, because my PkgUser Book has explicit sections for >> unpacking the sources that the vanilla book doesn't, that, >> in Chapter 5 GGC Pass2, the order of actions prior to the >> creation of the build directory is: >> >> >> Unpack the required external packages >> Change the location of GCC's default dynamic linker >> On x86_64 hosts, set the default directory name for 64-bit libraries to >> “lib”: >> >> >> however in GCC Pass 2, it's >> >> >> Create a full version of an internal header >> Change the location of GCC's default dynamic linker >> On x86_64 hosts, set the default directory name for 64-bit libraries to >> “lib”: >> Unpack the required external packages >> Fix a problem introduced by Glibc-2.31 >> >> >> Is there any reason why the required external packages can't be >> the first thing done in GCC Pass 2 as well? >> >> Indeed, is there any reason why the ordering in GCC Pass 2 >> couldn't be: >> >> >> Unpack the required external packages >> Change the location of GCC's default dynamic linker >> On x86_64 hosts, set the default directory name for 64-bit libraries to >> “lib”: >> Create a full version of an internal header >> Fix a problem introduced by Glibc-2.31 >> >> where the two actions not carried out in Pass 1 come >> after the three that are? >> >> Given that there is no reason given for the change in order, >> I think this would make the two Pass sections more similar, >> thereby highlighting the differences in the second pass. >> >> >> I could also suggest that the wording >> >> Now fix a problem introduced by Glibc-2.31: >> >> might be more explict about why, so perhaps: >> >> Now fix a problem introduced by the Glibc-2.31 we have just built: >> > > I think this will be removed in next version of gcc (as mentioned by Xi > Ruoyao), but in case this isn't, and glibc-2.32 appears, the problem will > still have been introduced by glibc-2.31, which we won't be building at all... > So no, in this case, I do not think we should change the wording. > > The problem actually is rather the use of line numbers in a sed, which is > really not explicit at all! But it was easier this way. > > BTW, I agree about reordering the commands.
Reordering done at r11788 Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
