Help with MinGW and 4.8 release candidate

[Ralf Corsepius]

On Wed, 2008-01-09 at 18:31 +1100, Chris Johns wrote:
> Ralf Corsepius wrote:
> > Instead of shooting at sight at what you don't like, we should analyze
> > the problem and find a solution.
> 
> I have taken a look at the code and see the following:
> 
> Newlib:
>   Writes to stderr and calls abort.
Both, presence of stderr and abort are mandated by POSIX.

> RTEMS:
>   Writes to printk and calls rtems_fatal_error_occurred.
Well, something I consider to be a short-cut/hack to avoid stderr and
abort.

> The RTEMS version allows asserts in newlib or any other library to be present 
> and to not have newlib's stdio being linked in.
The requirement for RTEMS always had been to avoid printf. It had not
been to avoid stdio (It's the reason why we systematically use fprintf
in RTEMS application code).

>  This is important for the 
> small footprint targets.
The question to me is more: What is Joel complaining about?

* Does newlib pull-in printf via assert into itself (this would be a
bug)?
* What is different in newlib-1.16.0 that causes the rtems __assert
becoming non-functional? I don't know the answer (yet?).

> So it would seem we have to resolve standards verses small footprint embedded 
> systems.
Right, but I prefer to put it a bit harsher: Which Standards does RTEMS
want to ignore in favor of hacks?

Sometimes, you've got to compromise. This definitely is a situation to
do so - In one or the other direction. My inclination goes towards POSIX
and not into the direction of artificial test cases (minimum).

> The standard requires the message be printed to stderr. Is printk always 
> stderr ? If we state stderr (outside of ptys or redirection) shall always 
> appear on the same device as printk would that be ok ?
I am not sure, but I am inclined to think so. 

This is at least along the lines to what we had done on the SH's during
the rtems-3.x/4.0 days (bummer, almost a decade ago :), when RTEMS
didn't have printk or a very early version of it.

> The standard requires assert call abort. The standard states abort shall cause 
> abnormal process termination unless the signal SIGABRT is being caught. We do 
> not handle signals so the SIGABRT issue is not important. The newlib code 
> calls exit which is nice but is it important to us. We should never get 
> asserts outside the development environment so a clean exit is not that 
> important. I would consider a watchdog and reset more important.
> 
> Looking at this code I wonder if abort should also be replaced (bucket or mug 
> at the ready :-)).
I'd have to look into source code at depth first, before being able to comment on it ;)

> I hope this helps.
Thanks.

Ralf