Is there any framebuffer testcases?

[Peng Fan]

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
-I/home/Freenix/development/rtems/4.12/arm-rtems4.12/raspberrypi/lib/include
   -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
-Wall -W
 -L/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/tmp/sb-Freenix/graphics/libtiff.bset/home/Freenix/development/rtems/4.12/lib
-o mkg3states mkg3states.o ../port/libport.la -lm -lc
libtool: link: arm-rtems4.12-gcc -DHAVE_GETOPT -Wall -W -o mkg3states
mkg3states.o
 -L/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/tmp/sb-Freenix/graphics/libtiff.bset/home/Freenix/development/rtems/4.12/lib
../port/.libs/libport.a -lm -lc
/home/Freenix/development/rtems/4.12/lib/gcc/arm-rtems4.12/6.0.0/../../../../arm-rtems4.12/lib/libc.a(lib_a-getopt.o):
In function `getopt':
/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160124-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/newlib/libc/stdlib/../../../../../gcc-6-20160124/newlib/libc/stdlib/getopt.c:461:
multiple definition of `getopt'
../port/.libs/libport.a(getopt.o):getopt.c:(.text+0x0): first defined here
/home/Freenix/development/rtems/4.12/lib/gcc/arm-rtems4.12/6.0.0/../../../../arm-rtems4.12/lib/libc.a(lib_a-getopt.o):
In function `permute':
/home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160124-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/newlib/libc/stdlib/../../../../../gcc-6-20160124/newlib/libc/stdlib/getopt.c:142:
multiple definition of `opterr'
../port/.libs/libport.a(getopt.o):(.data+0x0): first defined here

Thanks,
Peng

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 ...
> >
> >
> /home/Freenix/development/rtems/4.12/lib/gcc/arm-rtems4.12/6.0.0/../../../../arm-rtems4.12/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 0000000000008000
> >
> /home/Freenix/development/rtems/4.12/lib/gcc/arm-rtems4.12/6.0.0/../../../../arm-rtems4.12/lib/libc.a(lib_a-fclose.o):
> In function `_fclose_r':
> >
> /home/Freenix/work/forfun/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160124-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/newlib/libc/stdio/../../../../../gcc-6-20160124/newlib/libc/stdio/fclose.c:117:
> 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...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160408/1e9e86f6/attachment.html>