Re: Opinions requested

[Johannes Stezenbach <js at sig21 dot net>]

On Sun, Aug 22, 2010 at 04:26:43PM +0200, Yann E. MORIN wrote:
> On Sunday 22 August 2010 15:53:17 Harold Grovesteen wrote:
> > I realize this might be a special case with very limited  
> > applicability, but it is so simple and easily created I thought I would 
> > bring it up here.  I have never seen a crosstool build this simple.  If 
> > it is, maybe it should be documented somewhere.  What's the gotcha?
> 
> The 'gotcha' is that it is not standard. :-) A non-POSIX API is a bit weird.
...
> > My suspicion is that glibc and Linux bring the complexity to the build 
> > process.
> 
> Definitely.
...
> Indeed, your use-case seems to be very, very specific. Nonetheless, adding
> it to crosstool-NG might be feasible.
...
> >     --with-newlib \

AFAIK newlib is a bit limited but it still supports POSIX (depending on
target).  I've built toolchains with newlib myself for work on
bare-metal test code and boot code.  Newlib is insufficient
for complex userspace applications, but not everyone is targeting
Linux userspace.  E.g. CodeSourcery for ARM EABI (== baremetal) uses newlib:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294


The benfit of using crosstool-NG would be that you don't
have to spend time researching binutils + gcc bugs because
crosstool-NG includes the necessary patches.  (Well, at
least it should.  Or the other way round, if you did the research
you can share the result with other people.)

I've built toolchains with the simple script method initially
and then wasted a lot of time tracking down bugs caused by
wrong code generation, just to find that the issue was
long fixed and a patch already available.  I learned that
using official release tarballs of gcc etc. is not sufficient,
you need to check what other people have been using successfully
(e.g. Debian, OpenEmbedded).


Best Regards
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq