https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote: > - binutils, with a linker configured to look for system libraries in a > non-standard folder, empty for now > - gcc, without libstdc++ The first GCC should be --enable-languages=c --disable-shared --without-headers --with-newlib (where --with-newlib means "define inhibit_libc", as required to stop libgcc from needing libc headers in some cases) - you may need various other --disable- options for other GCC libraries that can't be built without glibc headers (see the full options used in glibc's build-many-glibcs.py for a list that is sufficient). In particular, libstdc++ should not be built until glibc has been built. > - glibc, using the above binutils/gcc, which fills in the non standard lib > folder with only a libc. > - libstdc++, using the above binutils/gcc/glibc. A second GCC should be built with all languages you want, shared libraries enabled (in particular, once you've built glibc you can build a proper shared libgcc with DT_NEEDED pointing correctly to libc, which you can't until glibc has been built). It's true that ideally the host-side code in GCC would be built just once (but libgcc built twice), but that's not currently supported by the GCC build system. > Note that this is just the beginning of the bootstrap. After this other > gcc/libstdc++ are being built, and this time the configure script works > unpatched. Two GCC builds suffice with modern (c. 2012 and later; GCC 4.9 and later, glibc 2.17 and later, roughly) tools. The stripped glibc shared libraries built with the first GCC using the above process should be identical to the stripped glibc shared libraries resulting from any longer alternating series of GCC and glibc builds.
