[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:

> - The stage2 compiler is built with --prefix=/usr and
> installed with the DESTDIR set to the build dir. As the
> result, this stage2 compiler can't build its libs! (libgcc, libstdc++)
> It can't build its libs because it is never installed
> into its prefix dir on host, and so I override its
> in-tree tools with the ones from the stage1 compiler.

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.

> > A plausible approach to fixing that if you can't use sysroots is to add a 
> > a new configure option whose purpose is to point to the build-time 
> > non-sysroot location of headers that should be used in building target 
> > libraries.
> 
> I think I tried this already, see comment #10.
> I did a hack to change the header pathes. And
> that worked, but then there are those -B options
> that prevented the libs from being found during
> configure process. So I found the change-headers-path

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.

The build system design is that where A and B are both built at the same 
time, and the build of B uses A, it should use the *newly built* copy of A 
as long as that is for $host = $build.  That applies for in-tree binutils 
(to the extent that anyone still builds those in a unified tree), and for 
in-tree host parts of GCC, and for in-tree libgcc when other target 
libraries use it, and so on - it's the universal design in the build 
system for all such dependencies.

It may be possible to hack things up to allow configuring and building an 
individual target library with an installed compiler, but that's a case 
where the tree in which you build that library is *not* one in which 
you've built host GCC at all (and then you pass a load of variables to 
"make all-target-libstdc++-v3" or whatever).  In general, if you don't 
want to build with the newly built copy of A you should configure and 
build in such a way that there isn't a newly built copy of A at all.