GSOC:disable newlibc reentrancy

[Joel Sherrill]

Went to lunch and realized I missed some of this and had
more thoughts.

Ralf Corsepius wrote:
> On Thu, 2008-05-08 at 10:05 -0500, Joel Sherrill wrote:
>   
>> That's not necessary.  We have always had at least two
>> non-POSIX but supported configurations:
>>     
> POSIX doesn't mean pthreads.
>
> It means printf, str*, mem*, malloc, etc. ...
>
>   
Technically all of those are ISO/ANSI C functions which
are in POSIX by inclusion and reference. 

But more importantly, just because than are in a standard
that we support doesn't mean they should be in every
executable.  They should be available to be used by any
application.
>> The primary features we are talking about being
>> more optional are C library reentrancy and filesystem.
>> Making either of those optional can be done without
>> the addition of a special configuration .
>>
>> I am nearly certain that you could no reentrancy
>> and no filesystem and RTEMS would be just as PSE51
>> compliant as long as you had POSIX enabled.
>>
>> Again just pieces and parts, no special compiles,
>>     
> Then remove this silly CONFIGURE*REENTRANCY crap you added to RTEMS.
>
> THIS makes builds using it a SPECIAL build and renders shipping binaries
> of cpukit IMPOSSIBLE.
>
>   
See previous comments but I think since you are missing
that changes to confdefs.h have no impact how cpukit is
built or its ability to be multilib'ed and shipped as a
binary, you are missing the benefit.

When provided as a binary, cpukit will be built in a single
configuration with an arbitrary set of options.  If using the
binary cpukit results in unused code being in an application
executable that would not be if RTEMS was built with
a different --enable/--disable configuration, then that reduces
the set of people willing to use the binary.  I want the cpukit
to be attractive and produce the same small executables
you would get by a custom build.  By providing finer grain
control over what code is linked in with standard builds
of cpukit and a BSP, there is less incentive to do custom
builds or (even worse) custom hacks.

More options in confdefs.h broadens the appeal of a pre-built
cpukit not eliminates its technical feasibility.

For example, my recent changes to the malloc family moved
MALLOC_STATS and MALLOC_DIRTY from options that required
a special build to application time configure options.  This
means that a cpukit binary user would have two less reasons to
recompile RTEMS.  That's a good thing not turning it into a toy.

> Ralf
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985