Is there any framebuffer testcases?

Wed Apr 13 13:19:21 UTC 2016

On Thu, Apr 7, 2016 at 8:23 PM, Peng Fan <van.freenix at gmail.com> wrote:

> 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
>
>
newlib has getopt but somehow the build system for this package turned
getopt()
support on in its adapter directory "port"

I did an experiment to see which symbols need to be added to
newlib/libc/sys/rtems/crt0.c
and came up with these:

_Mutex_Acquire
_Mutex_recursive_Acquire
_Mutex_recursive_Release
_Mutex_Release
posix_memalign

That should be enough to reference any symbol in libc.a and do a probe link
successfully.

However I was using ld directly so that doesn't really match how autoconf
probes do
the test. They use gcc to attempt to link and see if a symbol is present.
Something
like this should give us an idea what's missing:

sparc-rtems4.12-gcc -Wl,--whole-archive libc.a -Wl,-no-whole-archive -o
/tmp/a.out

This pulls in the entire C library and ensures we can resolve every
dependency on a
dummy/probe link. Because of the gcc libraries, this adds a few more
symbols which
need to be stubbed in crt0.c. There were a few more symbols doing that but
I think
the ones listed above are the critical ones.

We probably need to do the same analysis on gcc libraries to ensure that
they
link OK with the dummy crt0.o in newlib.

--joel

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/20160413/252ae16f/attachment-0002.html>