Hello,
I am trying to compile libcoap and I get a the error “multiple definition of `_kill_r’” with first definition in the file /cpu/stm32f3/syscalls.c. I do not get any compilation errors if I remove the function definition for _kill_r from this file. Does somebody already know why I am getting this error?
Thanks a lot for the help!
Regards,
Abhinav
Hi Abhinav,
to be short `_kill_r` is already defined in newlib (./newlib/newlib/libc/reent/signalr.c (lib_a-signalr.o)).
If your code never called this function before, e.g. when using the RIOT `hello world` example, no linkage is done either to the newlib `_kill_r` nor to the one in `./RIOT/cpu/stm32f3/syscalls.c`.
It seems that `libcoap` requires and calls this function and get in conflict with the two provided implementations.
I experienced exactly the same when building `riot_and_cpp` for `msba2`.
Best regards,
Martin
Thanks Martin,
So which implementation of the _kill_r should I be using. I am not sure
what this function actually does.
Regards,
Abhinav
Basically this function is an reentrant version of kill, which allows to send signals to other processes when the caller has the permission
(http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html).
I suggest to use the newlib implementation, as `_kill_r` does not provide a real implementation in RIOT.
Best regards,
Martin
Thanks a lot for the help.
Regards,
Abhinav
Hi Abhinav!
Actually, that sounds strange to me. Usually, we're not using the newlib
syscalls (therefore, the script
https://github.com/RIOT-OS/RIOT/blob/master/dist/tools/toolchains/build_gnuarm.sh
builds newlib with "--disable-newlib-supplied-syscalls"). I don't see why
`_kill_r` should be a problem, while it works fine (and as intended) with the
other syscalls.
For which board are you trying to build your example and which toolchain are
you using?
Cheers,
Oleg
Hi Oleg,
I am using an Stm32f3 board. I think I finally understand the problem! I am not using your makefiles to build the project. I am using a builder supplied by the Eclipse IDE (because it comes with an east to use GUI) with the GNU arm embedded toolchain. I just need to add this option to my build options.
Thanks,
Abhinav
Hi Somaraju Abhinav,
Sorry for digging this topic up ;-), but I also really want to
eliminate this compiling error without manually delete kill_r in
RIOT's syscall.c. However, I can't find the option you mentioned in
eclipse (I'm using gnu arm embedded toolchain too), so could you write
down a short introduction how to do this? I think it's very useful for
many people.
Cheers,
Nhat.
Hi Nhat,
Sorry about the late reply. Please see below for the build steps I used. Let me know if have any more questions.
Rgds,
Abhinav
Here are the steps I used to build the project for the STM board:
1) Start a new C project in Eclipse (I used the STM discovery Led Blink sample project).
2) Select Internal Eclipse Builder (Project->Properties->C/C++ Builder->Builder Settings)
3) Create New Folder within project (File->New Folder)
4) Import Required Folders from RIOT (File->Import->File System) into newly created directories. Repeat this step for all required directories. I needed to import the following : RIOT/core, RIOT/cpu/stm32f407vg, RIOT/cpu/cortex_common, RIOT/board/stmf4discovery.
5) Add header include paths for each imported folder (Project->Properties->C/C++ General->Paths and Symbols->includes).
6) I had my own debugger installed (which was using a macro with name DEBUG) and I had to change #define DEBUG to #define DEBUGRIOT for all occurrences in the folder RIOT/core
7) Add cpu name in preprocessor #defines (e.g. STMF429_439xx)
Note: You can also import multiple folders that you are not using and then exclude folders from build later on (right click on folder and select resource configuration). This allows you to (easily) change boards/cpus etc!
I am sorry but, I cannot remember what this option is in Eclipse. In my current code the RIOT implementation of _kill_r is commented out.
Regards,
Abhinav
Hi Abhinav,
Thanks. I really appreciated that. It seems that I must find this option by my self.
By the way, just a little curious, if you’re using internal builder of Eclipse how could you maintain the definitions which have been defined in RIOT’s Makefiles such as -DMODULE… -DBOARD_… ? I tried the internal builder a when I cloned RIOT for the first time. At this time, I thought it was too tiresome to maintain the build process so I decided to stick with RIOT’s makefiles by importing makefile project to Eclipse so it can use RIOT makefiles, and setting up my own openOCD.
Cheers,
Nhat.