This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PROPOSAL: Policy for obsoleting targets
Paul Koning wrote:
>
> >>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:
>
> Janis> On Fri, May 16, 2003 at 12:33:50PM -0500, Joel Sherrill wrote:
> >> Peter Barada wrote:
> >> >
> >> > > At the time GCC version 3.n is released, all targets which
> >> have not > > had a successful build and test report posted to
> >> gcc-testresults > > for prereleases of minor version n, or
> >> releases n-1 and n-2, go on > > the obsoletion list for version
> >> n+1. "Successful" means minimum > > useful functionality: it's
> >> okay if only the C compiler works.
> >> >
> >> > http://gcc.gnu.org/gcc-3.2/buildstat.html or >
> >> http://gcc.gnu.org/ml/gcc-testresults/2003-04/ only shows host >
> >> compilers, and no embedded targets(such as ppc-eabi, m68k-elf,
> >> etc).
> >> >
> >> > How do we prevent embedded targets(that are know to work fine)
> >> from > from being placed on the obsoletion list?
> >>
> Janis> [snip]
> >> This is why I try to report fairly regularly on targets I honestly
> >> don't use for real work. My thinking is that CPU-elf or CPU-coff
> >> is so close to CPU-rtems that any code generation problems are
> >> shared.
> >>
> >> Importantly for embedded targets without simulators, it can be
> >> painful to even run the suite requiring some significant effort to
> >> setup.
>
> Janis> I might regret this, but I'm now willing to add cross build
> Janis> reports to the GCC build status lists. If someone wants to
> Janis> suggest a list of what information such a report should
> Janis> include it could be linked from the beginning of the document.
> Janis> The list itself would probably just include something like
>
> Janis> <target triple> Cross build: 3.3
>
> Janis> where the "3.3" is a link to the archived message. In
> Janis> previous discussions about listing cross builds in the status
> Janis> lists, I've assumed that I would need to pull relevant
> Janis> information out of the messages about the host, target, and
> Janis> possibly build machine, and put it all into the entry in some
> Janis> organized way. If I can get away with merely adding
> Janis> simple-minded links, I no longer have objections to adding
> Janis> them to the list.
>
> Janis> It would be fine, by the way, for a report to include a long
> Janis> list of successful cross builds like the ones Joel does for
> Janis> RTEMS targets.
>
> Janis> So, back to the point of this thread: what kind of information
> Janis> would need to be included in reports of cross builds in order
> Janis> for those targets to be considered active?
>
> I think what you describe is good.
>
> My limited understanding of crossbuilds suggests that you can't
> sensibly build gcc by itself, you have to build it along with other
> stuff. So capturing information about what else was built, including
> what versions, would be useful.
>
> Finally, since it appears that no one has time or energy to document
> how crossbuilding works, would it be possible to ask cross-build
> status reporters to make available, if possible, the scripts they use?
> A pointer would be enough; copying it into the report is probably
> excessive. I'm thinking that perhaps I might be able to intuit what
> the crossbuild process is from looking at a sufficiently large sample
> of "scripts that just happen to work". What the heck, I might as well
> try, nothing else has worked...
I have been waiting to wade in on the cross cookbook issue and
now seems like the time.
The problem with cross build is that there is really no generic
"build a cross compiler" procedure. Based upon my experience,
I see a handful of patterns that have different procedures.
+ cross to another host with binutils support
- x86 GNU/Linux -> sparc-solaris or i386-cygwin
+ cross to a closed source host with no binutils support
- x86 GNU/Linux -> ?? (remote shell to native as/ld)
+ cross to a bare embedded board using newlib
- x86 GNU/Linux -> m68k-elf or arm-elf
+ cross to a bare embedded board using another C library
- x86 GNU/Linux -> avr-elf
+ cross to another CPU's GNU/Linux
- x86 GNU/Linux -> arm GNU/Linux
+ cross to a closed source RTOS
- x86 GNU/Linux -> VxWorks or LynxOS
+ cross to an open source RTOS
- x86 GNU/Linux -> RTEMS or eCos
+ ??? more
I used GNU/Linux as my example host because other hosts have their
own unique "features" for use in building tools. Cygwin and
Solaris always seem to require special steps that GNU/Linux doesn't.
So the common problems like Cygwin CR/LF problems or Solaris
not having a broken awk or sed have to be noted differently from the
procedure itself.
No one person is skilled in all those types of cross builds. I have
done about 4 of them in the past year. If GCC is to have good cross
building instructions, then my proposal would be to divide the
instructions
into categories based upon the above patterns and any others that people
can identify.
With the reduced scope on each category of cross, then the problem is
more approachable. And an option might be to get the experts in the
various types of crosses to submit their existing instructions.
> paul
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985