Re: Unclear documentation on building GCC together with binutils

[Brian Dessent <brian@dessent.net>]

Ulf Magnusson wrote:

> , or into the gcc-3.x.x directory with one directory level stripped
> (e.g. with --strip-components 1 passed to tar), essentially "merging"
> the two packages in foo/gcc-3.x.x? Whatever turns out to be The Right
> Way, the doc really needs to be updated for clarity.

Yes.  You want to merge both the contents of gcc and binutils into one
directory.  If you examine the structure of the source code, you will
find that they share the same "toplevel" infrastructure, and they are
designed to live in the same tree.  In other words, both the binutils
and gcc tarballs are subsets of one larger directory tree of code.  And
in fact it's not just gcc and binutils, it's all of sourceware: gcc,
newlib, binutils, gdb/insight, sim, cygwin, etc are all really one big
tree that share a common toplevel, and can be built that way if you are
adventurous.  The build machinery at the toplevel is supposed to be able
to build any one or all of these things at once, depending on what's
present.

When gcc still lived in CVS this was much easier, as there was the
"uberbaum" which was a single CVS tree that actually contained
everything that you could check out as one huge tree.  Now that gcc is
in SVN it's a little more separated, but the common toplevel files are
maintained in sync in both repositories.

When doing this from release tarballs though you will encounter some
problems in that each package will contain its own copy of some common
infrastructure, like libiberty/ and config/.  Due to this it can be a
little difficult to actually combine the trees because what you have is
two different vintages of some common things, depending on when each was
released.  You want to use the newer copy whereever a conflict exists,
but in some cases there will be older files that were deleted in one
version but the older one still expects them, so you really must combine
the two trees, not just select the newer of the two.  The script
"symlink-tree" in the toplevel is meant to help with this.  Google for
"combined tree build" for more information.

AFAIK this tradition originated at Cygnus Solutions, and thus it is not
surprising that it's still used a lot in some circles given that a great
number of gcc/binutils developers used to work at Cygnus or continue to
work for Redhat after they merged.

> Why would you want to build gcc and binutils together in this way by
> the way? Isn't it possible to install them separately?

It can be a lot more convenient.  For example, for a cross-toolchain,
the normal procedure would be:

configure cross-binutils
build cross-binutils
install cross-binutils
adjust PATH to make just-installed files available
move to another build dir
configure cross-gcc
build cross-gcc
install cross-gcc
etc...

However, the build infrastructure knows that if you are building in a
combined tree, to use the just-built in-tree tools where necessary, so
that nothing has to be installed.  The procedure then becomes just:

configure combined tree
build combined tree
install combined tree

This builds everything at once, in one place, instead of as a chain of
stages.  And likewise, you can add newlib/gdb/insight into this mix, so
this becomes very convenient for people that work with cross-toolchains.

Its benefit may not be very obvious to you if all you care about is
native tools that use the existing host tools or host libc, but for a
cross situation those tools don't exist it can make things a lot easier.

This especially true for targets where you'd don't have easy access to
existing libc headers, as there is a chicken-and-egg problem of "can't
build a fully functional gcc without libc headers" and "can't build libc
without a functional gcc."  The common way to solve this is to drop
newlib into the tree and do a combined build of both at once, which
breaks the circular dependency.  (Another way to solve it, for cases
where you aren't using newlib and can't do a combined tree, is the way
crosstool does it, by first building a stripped down C-only gcc, using
that to configure the libc enough to get its headers, then build a full
gcc using those headers, then build the full libc using that gcc.)

And keep in mind that these subdirs are always modular, so that even if
you are working in a combined tree, if you just want to remake one
component (or just install one component) you can just cd into that dir
and work from there.  It just gives you the flexibility to either
build/install everything at once or work in specific areas.

Brian