compiler error - multiple definition of `_kill_r'

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. :slight_smile: 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. :smiley: 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.