<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 8:23 PM, Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">There is another errors in the log file, multiple getopt definition. I do not have clear idea on this.<div><br><div><div>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</div><div>mv -f .deps/mkg3states.Tpo .deps/mkg3states.Po</div><div>/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/<a href="http://libport.la" target="_blank">libport.la</a> -lm -lc </div><div>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</div><div>/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':</div><div>/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'</div><div>../port/.libs/libport.a(getopt.o):getopt.c:(.text+0x0): first defined here</div><div>/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':</div><div>/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'</div><div>../port/.libs/libport.a(getopt.o):(.data+0x0): first defined here</div></div></div><div><br></div></div></blockquote><div><br></div><div>newlib has getopt but somehow the build system for this package turned getopt() </div><div>support on in its adapter directory "port"</div><div><br></div><div>I did an experiment to see which symbols need to be added to newlib/libc/sys/rtems/crt0.c</div><div>and came up with these:</div><div><br></div><div><div>_Mutex_Acquire</div><div>_Mutex_recursive_Acquire</div><div>_Mutex_recursive_Release</div><div>_Mutex_Release</div><div>posix_memalign</div></div><div><br></div><div>That should be enough to reference any symbol in libc.a and do a probe link successfully.</div><div><br></div><div>However I was using ld directly so that doesn't really match how autoconf probes do</div><div>the test. They use gcc to attempt to link and see if a symbol is present. Something</div><div>like this should give us an idea what's missing:</div><div><br></div><div><div>sparc-rtems4.12-gcc -Wl,--whole-archive libc.a -Wl,-no-whole-archive -o /tmp/a.out</div></div><div><br></div><div>This pulls in the entire C library and ensures we can resolve every dependency on a</div><div>dummy/probe link. Because of the gcc libraries, this adds a few more symbols which</div><div>need to be stubbed in crt0.c. There were a few more symbols doing that but I think</div><div>the ones listed above are the critical ones.</div><div><br></div><div>We probably need to do the same analysis on gcc libraries to ensure that they</div><div>link OK with the dummy crt0.o in newlib.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks,</div><div>Peng</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-04-08 8:38 GMT+08:00 Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><p dir="ltr"><br>
On Apr 7, 2016 7:47 PM, "Chris Johns" <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br>
><br>
> On 7/04/2016 11:20 PM, Peng Fan wrote:<br>
>><br>
>> Sorry. Missed to attach error info when compile tiff<br>
>><br>
>> Please kindly give comments on this.<br>
>><br>
><br>
> From the log ...<br>
><br>
> /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<br>
> /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':<br>
> /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'<br>
><br>
> This looks like a regression with RTEMS related to the addition of _Mutex_recursive_Release and friends.<br>
><br>
> 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<br>
><br>
> I think these symbols are related to changes in gcc and/or newlib.<br>
><br>
><br>
> 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.<br>
><br>
> I hope someone who knows what happens here can offer some advice.<br>
></p>
</span><p dir="ltr">I'll take that bait but disclaim that I am on a subway train and answering on my phone.</p>
<p dir="ltr">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. </p>
<p dir="ltr">The second tier is dummy.c in libmisc/dummy (I think). It is a default configuration and doesn't provide dummy symbols.</p>
<p dir="ltr">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.</p>
<p dir="ltr">I am not sure how to test this except to take a link against every symbol individually in the C library without RTEMS.</p>
<p dir="ltr">> Chris<br>
> _______________________________________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
</p>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>