linux/posix port compiling problem

Ralf Corsepius ralf.corsepius at rtems.org
Wed Apr 15 03:46:15 UTC 2009


Chris Johns wrote:
> Ralf Corsepius wrote:
>> Joel Sherrill wrote:
>>> Looking at the patch, it looks like it boils down to 3 things:
>>>
>>> + disable shell for posix port (easier to drop it from building at all).
>> Well, rtems shell got infected with with newlib-proprietary, 
>> non-portable construct.
> 
> Is this the getopt_r call you are referring too ?
Yes, this is one aspect.

Another one is code using newlib proprietary/internal headers.

>> IMO, we should get rid of them and either re-write the code or abandon it.
>>
> 
> I do not know what code you are referring to here, shell, linux-posix BSP or 
> something else ?
All of them :-)

My point is: There are parts in RTEMS which once used to be portable/ 
compilable with non-newlib-based toolchains and now aren't anymore.

So far, the only use case these situations show, is the unix/posix BSP.
=> we need to decide on how to handle these.

I see 2 options:
- Treat these non-portable spots as "regressions" that ought to be 
fixed. libmisc/shell and the malloc issues are such cases.

- Treat the cases triggering the issues as "now unsupported/obsolete"
=> Remove the Unix/posix BSP.

A 3rd option would be what Joel outlined: Suppress the "regression" for 
unix/posix by disabling them. I am not excited about this option, 
because it further reduces the unix/posix's BSPs usefulness.

Ralf






More information about the users mailing list