Recently there are some people building GCC with srcdir == objdir and the attempts just failed [1]. So stop to say "it should work". OTOH objdir as a subdirectory of srcdir works: we've built GCC in LFS [2] and BLFS [3] this way for decades and this is confirmed during the review of a previous version of this patch [4].
[1]: https://gcc.gnu.org/pipermail/gcc-help/2023-November/143068.html [2]: https://www.linuxfromscratch.org/lfs/view/12.0/chapter08/gcc.html [3]: https://www.linuxfromscratch.org/blfs/view/12.0/general/gcc.html [4]: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638760.html gcc/ChangeLog: * doc/install.texi: Deem srcdir == objdir broken, but objdir as a subdirectory of srcdir fine. --- Superseds https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638728.html. Ok for trunk? gcc/doc/install.texi | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index c1ccb8ba02d..c1128d9274c 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -697,9 +697,8 @@ phases. First, we @strong{highly} recommend that GCC be built into a separate directory from the sources which does @strong{not} reside within the source tree. This is how we generally build GCC; building -where @var{srcdir} == @var{objdir} should still work, but doesn't -get extensive testing; building where @var{objdir} is a subdirectory -of @var{srcdir} is unsupported. +where @var{objdir} is a subdirectory of @var{srcdir} should work as well; +building where @var{objdir} == @var{srcdir} is unsupported. If you have previously built GCC in the same directory for a different target machine, do @samp{make distclean} to delete all files -- 2.43.0
