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
