On Tue, Apr 17, 2018 at 3:35 AM, Amaan Cheval
wrote:
> Great tips, thank you for the help!
> Updating the bsp_specs to replace startfile with crtbegin.o did let me get
> past the the __getreent problems. It seems like I'll need to learn much
> more about linker scripts and the GCC spec syntax tha
On 17/04/18 10:35, Amaan Cheval wrote:
- https://docs.rtems.org/branches/master/bsp-howto/linker_script.html
You have to be careful with the BSP guilde. It is a bit out of date. For
a reference linker command file I would use this:
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared
Great tips, thank you for the help!
Updating the bsp_specs to replace startfile with crtbegin.o did let me get
past the the __getreent problems. It seems like I'll need to learn much
more about linker scripts and the GCC spec syntax than I currently know to
do this right - I've currently only worke
Hello,
you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib
provides a crt0.o file which contains a bunch of global symbols suitable
enough to make the GCC link-time configure tests happy. This file must
never be used for a real RTEMS application. The default startfile of GCC
libc, which
> > defines __getreent.
> > - Use the arch's gcc to compile any test that includes confdefs.h or as a
> > quick test (slightly quicker than locating crt0.o and analyzing symbols):
>
> > -> % echo "void __getreent(){}" | i386-rtems5-gcc -xc
-
> ...
> GNU C11 (GCC) version 7.3.0 20180125 (RTEMS 5, RSB
> c9db1326ef99e3e1267d17d2c7e5e51a48d1be2a, Newlib 3.0.0) (i386-rtems5)
>
> /tmp/cc90vvoP.o: In function `__getreent':
> :(.text+0x0): multiple definition of `__getreent'
> ---
> Next steps:
&g
U C11 (GCC) version 7.3.0 20180125 (RTEMS 5, RSB
c9db1326ef99e3e1267d17d2c7e5e51a48d1be2a, Newlib 3.0.0) (i386-rtems5)
/tmp/cc90vvoP.o: In function `__getreent':
:(.text+0x0): multiple definition of `__getreent'
---
Next steps:
- Figure out how __getreent is actually meant to be used
On 22/06/2015 3:24 am, Sujay Raj wrote:
> @Chris , I used 'target_link_libraries' in mk_bin/CMakeLists.txt to
> link libc.a and libbsd.a to the monkey-bin target
I think touching anything in Cmake with the hack around we have using is
only going to cause issues. We are currently working around cm
e
>the
>>> final executable , I get an error:
>>>
>>>
>>/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/librtemscpu.a(default-configuration.o):
>>> In function `__getreent':
>>>
>>>
>>/home/raaj/d
sps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/librtemscpu.a(default-configuration.o):
>> >> In function `__getreent':
>> >>
>> >>
>>
>> >/home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpuk
_getreent':
> >>
> >>
>
> >/home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
> >> multiple definition of `__getreent'
> &g
9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
>> multiple definition of `__getreent'
>>
>>
>/home/raaj/development/rtems/4.11/tools/lib/gcc/arm-rtems4.11/4.9.2/../../../../arm-rtems4.11/lib/thumb/armv7-a/neon/hard/libc.a(lib_a
In function `__getreent':
>
> /home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
> multiple definition of `__getreent'
>
> /home/raaj/development/rtems/4
pukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
multiple definition of `__getreent'
/home/raaj/development/rtems/4.11/tools/lib/gcc/arm-rtems4.11/4.9.2/../../../../arm-rtems4.11/lib/thumb/armv7-a/neon/hard/libc.a(lib_a-getreent.o):
/home/raaj/develop
14 matches
Mail list logo
