Re: TenDRA C and newlib

["Pedro Fernando Giffuni" <pfgiffun at bachue dot usc dot unal dot edu dot co>]

Joel Sherrill wrote:
> 
> Pedro Fernando Giffuni wrote:
> >
> > I know, it was just an experiment that shows:
> >
> > 1) that the configure script expects to use gcc and ONLY gcc.
> 
> This is from autoconf (a GNU package) so it should not be a
> surprise that configure works best with the GNU tools.
> 
> This applies generally to all packages using GNU autoconf/automake.
> 

No. on the other packages I have tested for portability, autoconf passes
well the compiler options. TenDRA is very strict though, and that's why
I am starting to like it. The fancy features are a plus right now, but I
would expect them to be very helpful for multiplatform support.

> > 2) that newlib is not really portable.
> 
> We have been through this statement with RTEMS.  Imagine trying to
> use a compiler whose primary interface is a GUI with its own packaging
> notions.  Even uglier.
> 
> The code in newlib/RTEMS is mostly portable.  The build structure is
> dependent on a UNIX-ish environment using a command line oriented
> compiler much like gcc.  If a particular file uses a GNU extension,
> that is a different matter.
> 
> Some embedded people find it easier to write a shell script wrapper
> that makes a non-GNU toolset look like the GNU equivalent.
> 

That's no excuse though... :-).

> > A heads up! for the cygnus maintainers, I guess.
> 
> I doubt it. :)
> 
> I personally have not tried this but I believe that there is a way to
> override both the compiler and the compiler flags on the command line.
> usually something like:
> 
> CC=XXX AS=XXX CFLAGS=XXX configure ...
> 
This usually works, but the particular configure scripts in the latest
newlib add -fno-builin ALWAYS.

> But since this is technically a package for cross-compilation, the
> variables
> may be different.
> 
> I am just saying that you need to address how to build the code
> separately
> from the portability of the code itself.  Big distinction.
> 
I understand this (My crosssco port in FreeBSD uses gmake and works
fine), but the world out there is not exclusively GNU.

Ohh..well, no more ranting on my part. If anyone want to fix the
problems, I'm willing to test patches (The gcc specific options were
very easy to get rid of, but I don't know if gcc likes my solution :).

cheers,

     Pedro.