building binutils from same directory as gcc (was: Re: xgcc does not find gcc-4.6.0-go/./binutils/ar (because it is gcc-4.6.0-go/./binutils/binutils/ar))

[Steffen Dettmer]

On Sat, Apr 30, 2011 at 12:38 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> I tried to express this in this form:
>> --- 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
>> +via SVN, it is reliable. Unpacking into the same directory means
>> +that the contents of the (versionized) directories of binutils
>
> versionized?

Thank you, "versioned" seems to be the word I was looking for.

>> What should I do now, mail to gcc-patches?
>
> Yes, patches should always be sent there for discussion and review.

ok, so I Cc:.



* http://gcc.gnu.org/contribute.html:
> Legal Prerequisites

None ("Small changes can be accepted without a copyright
disclaimer or a copyright assignment on file")

> 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.

> Testcases

None. I don't know whether to add a doc test and how to do so.

> ChangeLog

2011-05-02 Steffen Dettmer <steffen@dett.de>

	* doc/install.texi (Downloading the Source): Recommended
	not to build binutils in combined mode when using release
	tarballs.

(to be replaced this by a correct one if an improvement based on
the proposal in form of my patch is considered for a commit)

> Bootstrapping and testing

This change was not tested at all.

> The patch itself

--- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-4_6_0_gcc_doc_install.texi.diff
Type: application/octet-stream
Size: 1330 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20110502/6f6d4886/attachment.obj>