https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #24 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 > > --- Comment #23 from Stas Sergeev <stsp at users dot sourceforge.net> --- > (In reply to jos...@codesourcery.com from comment #22) > > On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > > And overriding like that is fundamentally unsafe, because in general in a > > multi-stage build (such as for a cross to GNU/Linux where the first stage > > is a static-only C-only compiler) the libraries have to be built with the > > more-fully-featured compiler built in the same stage - not with the > > previous stage's compiler. > > But isn't there always a possibility to add > one more stage? Say, in the example above where > at stage1 we only have a static-only compiler, > we could add stage2 and stage3. stage2 is a fully-featured > compiler to build stage3. I think this approach > will always work, just use N+1 stages. It's desirable to reduce the number of stages, not increase it. (Bootstrapping such a GNU/Linux toolchain used to take three stages, which was successfully reduced to two by fixing glibc to build with the first-stage GCC.) > > Then maybe an option is needed to find both headers and libraries in the > > non-sysroot case (where the option for libraries gives the top-level > > directory under which subdirectories for each multilib, using the multilib > > OS suffix, can be found). An option to find the build-time equivalent of > > $exec_prefix/$target, with lib and include subdirectories, say. > > And then why such an option is not called --with-build-sysroot? > In comment #11 you say > "there is no non-sysroot-headers equivalent of --with-build-sysroot", > but I don't understand what do you mean. Can we use --with-build-sysroot > w/o --with-sysroot, making it exactly an option you describe > above? The --with-build-sysroot option gives the location of a directory that uses the sysroot layout, which is not the same as that of a non-sysroot $exec_prefix/$target - unless your non-sysroot layout does not use /usr. If you set up the toolchain so that it thinks /include rather than /usr/include is the native system header directory, then you can use --with-sysroot and --with-build-sysroot without any temporary usr -> . symlinks. Otherwise, you can still use them, but need such symlinks during the build process. That is, --with-build-sysroot already works for the sort of thing you want to do, provided (a) you have the usr -> . symlink and (b) you configure using --with-sysroot even though it's logically not a sysrooted toolchain.