Is there any framebuffer testcases?
van.freenix at gmail.com
Fri Apr 8 01:23:04 UTC 2016
There is another errors in the log file, multiple getopt definition. I do
not have clear idea on this.
arm-rtems4.12-gcc -DHAVE_CONFIG_H -I. -I../../tiff-4.0.2/libtiff
-DHAVE_GETOPT -Wall -W -MT mkg3states.o -MD -MP -MF .deps/mkg3states.Tpo
-c -o mkg3states.o ../../tiff-4.0.2/libtiff/mkg3states.c
mv -f .deps/mkg3states.Tpo .deps/mkg3states.Po
/bin/sh ../libtool --tag=CC --mode=link arm-rtems4.12-gcc -DHAVE_GETOPT
-o mkg3states mkg3states.o ../port/libport.la -lm -lc
libtool: link: arm-rtems4.12-gcc -DHAVE_GETOPT -Wall -W -o mkg3states
../port/.libs/libport.a -lm -lc
In function `getopt':
multiple definition of `getopt'
../port/.libs/libport.a(getopt.o):getopt.c:(.text+0x0): first defined here
In function `permute':
multiple definition of `opterr'
../port/.libs/libport.a(getopt.o):(.data+0x0): first defined here
2016-04-08 8:38 GMT+08:00 Joel Sherrill <joel at rtems.org>:
> 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.
> > Chris
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users