Is there any framebuffer testcases?
joel at rtems.org
Fri Apr 8 00:38:35 UTC 2016
On Apr 7, 2016 7:47 PM, "Chris Johns" <chrisj at rtems.org> wrote:
> On 7/04/2016 11:20 PM, Peng Fan wrote:
>> Sorry. Missed to attach error info when compile tiff
>> Please kindly give comments on this.
> From the log ...
warning: cannot find entry symbol _start; defaulting to 0000000000008000
In function `_fclose_r':
undefined reference to `_Mutex_recursive_Release'
> This looks like a regression with RTEMS related to the addition of
_Mutex_recursive_Release and friends.
> RTEMS should link an executable without error because we need this
working so configure link tests do not fail when they should not. In this
case it is the an application 'mkg3states' that is being linked and this
use to work
> I think these symbols are related to changes in gcc and/or newlib.
> I seem to remember a dummy.c file or something like that which had some
symbols we needed so the link not fail like this.
> I hope someone who knows what happens here can offer some advice.
I'll take that bait but disclaim that I am on a subway train and answering
on my phone.
There are two tiers to this. The first is a dummy crt0.c in libc/sys/rtems.
This is used by autoconf type probes when NOT building against a BSP.
The second tier is dummy.c in libmisc/dummy (I think). It is a default
configuration and doesn't provide dummy symbols.
This case looks like the newlib dummy crt0.c is missing some symbols
normally provided by RTEMS. There is probably more than one of the new
mutex symbols missing.
I am not sure how to test this except to take a link against every symbol
individually in the C library without RTEMS.
> users mailing list
> users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users