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.

Reply via email to