On Wed, Oct 4, 2017 at 11:25 AM, Joseph Myers <jos...@codesourcery.com> wrote: > There are over 25000 words of GCC installation documentation in > install.texi, and that's not even including e.g. libstdc++ configure > options documented elsewhere. Other toolchain components also have such > documentation. > > It's true that, as a consequence of the toolchain being made up of > multiple separately maintained components, the documentation focuses on > configuration of a single build of a single component, not on issues > relating to composing multiple such builds, of the same or different > components, into a complete toolchain - you have to digest large amounts > of documentation of individual components and deduce from that how to > compose multiple builds to solve your particular problem (which is quite > likely different from anyone else's particular problem - and there's a lot > to digest to even get a clear enough conceptual understanding of what > one's problem is and what the end result might look like). > > But there are also plenty of toolchain build packages out there that do > such composition, and even if each of those is solving a problem different > from the one you have, studying those packages should give useful > information about how multiple builds are composed that helps you develop > your own such package. For example, I'd advise anyone wishing to > understand how to bootstrap a cross toolchain for a target using glibc to > look at the build-many-glibcs.py script in glibc that I wrote, as it uses > the preferred modern approach for building such a toolchain, whereas many > build scripts out there have workarounds for issues with old versions of > GCC or glibc that are no longer preferred or needed with current versions, > into which many improvements have gone to make building such a toolchain > smoother.
Sorry to step in if its unwanted. Part of the problem is separating the wheat from the chaff. That is, it's an information management problem. In 2017, the web in general and wiki's in particular are used for long term and evolving information dissemination. Its hard to find mailing list results, and its hard to find indexed readme results. Many projects don't realize the landscape has changed, and they cling to old habits as if the world is stuck in the 1980's. Of the thousands of hits when searching for the information on a task like compiling GCC, there's probably a handful of good sources. Everything else is just crap on the web that someone decided to blog about. (This is speaking from experience). OpenSSL used to suffer that problem too (and still does to some extent). Everyone who managed to generate an RSA keypair or certificate from the command line blogged about it. The results masked the really useful information, like how to generate a certificate with a hostname in the SAN (required by most modern user agents) and not the CN (default openssl). Another OpenSSL example is, nearly all build and configuration questions stopped on the mailing list once (1) OpenSSL created a wiki and (2) the wiki added https://wiki.openssl.org/index.php/Compilation_and_Installation. The information is readily available with provenance; and there's little need to read a blog, find a mailing list post or read a README. Maybe some of the first steps is to (1) recognize the information management problem, and (2) provide information dissemination that's {amicable|consistent|?} with what's occurring in 2017. I mean, README's were fine in the 1980's but with the advent of the web, users do different things nowadays. For completeness, GCC has a wiki. But I still don't have an account to make an occasional update; and I still don't know how to get an account. I tried to get one in the past but the process was broken so I gave up. Jeff
