I see this was not applied, and also did not get any review comments.
Let me add our build system maintainers.
If something like this goes in, I suggest to avoid direct references
to SVN (which is a technical detail) and use something more generic
and spell GCC as opposed to gcc when it refers to the overall project.
My other note is that this is too complicated. Why not just declare
that building from the same directory is not support and have one
simple set of instructions that always works, as opposed to "this
ought to work with snapshots but not with direct checkouts"?
Thoughts?
(If Steffen provides an updated patch based on this and/or your
feedback, I'll be happy to apply it if approved.)
Gerald
On Mon, 2 May 2011, Steffen Dettmer wrote:
>> A description of the problem/bug and how your patch addresses it.
>
> Users of release tarballs could get confused how to build
> binutils and gcc and accidently attempt an undesired "combined
> build". The patch adds some explaining words.
>
> 2011-05-02 Steffen Dettmer <stef...@dett.de>
>
> * doc/install.texi (Downloading the Source): Recommended
> not to build binutils in combined mode when using release
> tarballs.
>
> --- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.000000000 +0100
> +++ gcc-4.6.0/gcc/doc/install.texi 2011-05-02 14:39:01.000000000 +0200
> @@ -553,7 +553,17 @@
> If you also intend to build binutils (either to upgrade an existing
> installation or for use in place of the corresponding tools of your
> OS), unpack the binutils distribution either in the same directory or
> -a separate one. In the latter case, add symbolic links to any
> +a separate one. Using the same directory is not recommended for
> +building release tarballs of gcc, but if you obtained the sources
> +via SVN, it is reliable. Unpacking into the same directory means
> +that the contents of the (versioned) directories of binutils
> +and gcc are in one and the same directory (with subdirectories
> +like @file{gcc}, @file{binutils} and @file{gas}). Contents of the
> +directories common to and shared by gcc and binutils
> +(@file{include}, @file{libiberty} and @file{intl}) must be
> +compatible, making combined builds using standard releases hard
> +to get right. In case you are using separate directories, which
> +is recommended, add symbolic links to any
> components of the binutils you intend to build alongside the compiler
> (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
> @file{opcodes}, @dots{}) to the directory containing the GCC sources.
>
