GSOC:disable newlibc reentrancy

[Joel Sherrill]

Ralf Corsepius wrote:
> On Thu, 2008-05-08 at 10:05 -0500, Joel Sherrill wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> On Thu, 2008-05-08 at 15:46 +0200, Sven.BIEBAUT at be.thalesgroup.com
>>> wrote:
>>>
>>>
>>>       
>>>>> For bare-metal targets nobody needs RTEMS. He needs a minial
>>>>> scheduler library.
>>>>>
>>>>>
>>>>>           
>>>> with a lot of evidence and years of correct working history, support for
>>>> lots of different processors and a large supporting user base
>>>>
>>>> And the possibility to add com ponents as your system requires it during its
>>>> 20 odd years of support to the customer !
>>>>
>>>>         
>>> Rip out score, throw away all the historic ballast, and turn it into a
>>> standalone library.
>>>
>>> It wouldn't be an OS nor RTEMS anymore, but it would be an RTEMS
>>> api-complicant scheduler library. No need for a special compiler, no
>>> newlib, simply use a bare metal cross-compiler.
>>>
>>> The price: no POSIX, no c++, no networking, no ...
>>>
>>>
>>>       
>> 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. ...
>
>   
>> 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.
>   

Ralf.. it doesn't.  I don't know what it is going to take to
make you see that configures in confdefs.h have no impact
on how cpukit is built.

[joel at iceland cpukit]$ pwd
/home/joel/rtems-4.9-work/rtems/cpukit
[joel at iceland cpukit]$ grep -rl REENTRANCY .
./sapi/include/confdefs.h

All it does in there is add a static user extension to the
configuration table.  And the configuration table is
only instantiated when the application configured -- long
long after cpukit is built.

confdefs.h is referenced in only two places in cpukit:

[joel at iceland cpukit]$ grep -rl rtems/confdefs.h . | grep [.ch]$
./sapi/include/confdefs.h
./libmisc/dummy/dummy.c

The first is the actual file and the second is the dummy
base configuration needed to link when running an
autoconf link test.

Adding configuration points to confdefs.h has no impact
on multilib'ing cpukit -- it only impacts application
configuration time.

> 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