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