Re: Exhaustive Instructions for Toolchain Generation

[R0b0t1 <r030t1 at gmail dot com>]

On Wed, Oct 4, 2017 at 5:34 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 3 October 2017 at 22:27, R0b0t1 wrote:
>> I decline to do your company's market research for them. They could choose
>> to pay me, of course. Based on the failures I am experiencing I doubt that
>> your company has gotten the build process entirely correct.
>
> Given that you apparently only recently learnt about --sysroot it
> seems a bit presumptuous to assume Codesourcery's experts don't know
> what they're doing.

I admit no great knowledge of GCC, which is why I am asking questions
here. I have attempted to compile many different configurations

However, in my experience, open source efforts typically exceed the
functionality of their closed source counterparts, save the times when
information is kept secret. E.g. Microsoft Hyper-V had GPU passthrough
far before it was completed using open source technologies, but that
was due to vendor collusion.


On Wed, Oct 4, 2017 at 10:25 AM, Joseph Myers <joseph@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.
>

Thank you, I expect the specific example you gave to prove useful.
What you detailed in general was exactly what I have been doing. I
have no doubt that I can make something that works - my concern is
that I am encountering intermittent and hard to troubleshoot issues
that I suspect are due to faulty configuration.

Also as you point out, there is lots of documentation. That is why I
asked if there was a list of edge cases. There is, but it looks like
the purpose is something different. I may have to resort to fixing
problems as they appear, which is something I wanted to avoid.

Respectfully.
     R0b0t1