On 28 April 2011 15:26, Steffen Dettmer wrote:
> On Wed, Apr 27, 2011 at 5:02 PM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
>>> Is my assumption, that a "combined build" is most easy, a wrong
>>> one and should I try a non-combined build?
>>> Are there some docs about?
>>
>> I guess I just said this, but when using releases I would advise a
>> non-combined build.
>>
>>> For the documentation, especially extraction of bintuils, would
>>> it be a good idea to submit a bug report about the too brief
>>> installation instructions?
>>
>> Sure. Or send a patch. Thanks.
>
> I don't think I'm competent enough but maybe I can send some proposal...
>
>>> But there is a way to build a recent released gcc toolchain,
>>> isn't there?
>>
>> Of course. Just don't use a combined build.
>
> I tried to express this in this form:
>
> ------------------------------------------------------------------->8=======
> --- 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-04-28 15:59:53.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 (versionized) directories of binutils
versionized?
> +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.
> =======8<-------------------------------------------------------------------
>
> in the hope it could may be a base for an improvement?
> What should I do now, mail to gcc-patches?
Yes, patches should always be sent there for discussion and review.
