0

I am working on two Beaglebone Black with Xenomai and RTnet. I have two c-files for a roundtrip ethernet frame between the BBB's. When I try to compile the first c-file there occur some errors:

undefined reference to 'rt_task_self'

rt_task_self is a function in my c-file and is declared in my headerfile "task.h". So in my opinion "undefined" means that it is just not defined in any cpp-file "task.cpp" for the headerfile "task.h".

But I am a little bit confused: How do I tell my program that my headerfile "task.h" is defined in my other file "task.cpp" or "task.o" or... I have many header files in my C-file but only error with my "task.h" file and I do not see any differences in the #include rows between my "task.h" and all the other header files.

Part of Roundtrip C-file:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <unistd.h>

/*XENOMAI*/
#include "task.h"
#include <rtdm/rtdm.h>
#include <asm/ioctl.h>

#define SERVER "192.168.127.10"
#define BUFLEN 512
#define PORT 8888

void die(char *s)
{
    perror(s);
    exit(1);
}

Part of task.h:

#ifndef _XENO_TASK_H
#define _XENO_TASK_H

#include <nucleus/sched.h>
#include <native/types.h>

/* Creation flags. */
#define T_FPU     XNFPU
#define T_SUSP    XNSUSP
/* <!> High bits must not conflict with XNFPU|XNSHADOW|XNSUSP. */
#define T_CPU(cpu) (1 << (24 + (cpu & 7))) /* Up to 8 cpus [0-7] */
#define T_CPUMASK  0xff000000

Part of another headerfile in the roundtrip c-file:

#ifndef _RTDM_H
#define _RTDM_H

#ifdef __KERNEL__

#include <linux/types.h>
#include <linux/fcntl.h>
#include <linux/ioctl.h>
#include <linux/sched.h>
#include <linux/socket.h>

typedef u32 socklen_t;
typedef struct task_struct rtdm_user_info_t;

#else /* !__KERNEL__ */

#include <fcntl.h>
#include <stddef.h>
#include <stdint.h>
#include <sys/ioctl.h>
#include <sys/socket.h>

My makefile:

# Allow overriding xeno-config on make command line
XENO_CONFIG=xeno-config

prefix := $(shell $(XENO_CONFIG) --prefix)

ifeq ($(prefix),)
$(error Please add <xenomai-install-path>/bin to your PATH variable)
endif

CC := $(shell $(XENO_CONFIG) --skin=posix --cc)
STD_CFLAGS  := $(shell $(XENO_CONFIG) --skin=posix --cflags) -g
STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=posix --ldflags) -g -lrtdm

STD_TARGETS := rtt_rt

all: $(STD_TARGETS)

$(STD_TARGETS): $(STD_TARGETS:%=%.c)
    $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)

clean:
    $(RM) -f *.o *~ $(STD_TARGETS)
Checka
  • 45
  • 1
  • 1
  • 12
  • You've tagged this with [tag:makefile], but not presented or even described anything to do with a makefile. Edited. – John Bollinger May 22 '19 at 14:03
  • Possible duplicate of [What is an undefined reference/unresolved external symbol error and how do I fix it?](https://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix) – John Bollinger May 22 '19 at 14:05
  • Sry I forgot my makefile. Edited it – Checka May 22 '19 at 14:21
  • I have read the link you wrote. But I don't really understand how to compare those with my Makefile. I don't use link commands like ````$ g++ src1.o src2.o -o prog````. I am just using my Makefile – Checka May 23 '19 at 08:20
  • `make`, under control of your makefile, executes compilation and link commands. And at least one of those is wrong, either because it's not linking all the needed objects together, or because it's not linking a needed external library. The dupe target explains all that very well. `make`'s output contains all the commands `make` runs (not many, in your case), which will help you pinpoint where it's going wrong *and* how. – John Bollinger May 23 '19 at 11:57
  • Okay and how can I say "task.h belongs to task.c". I mean that cannot be done by my Makefile can it? Because it depends on which C-Program I am using. So where do I say the definition of all the function of ``task.h`` is written in ``task.c``? – Checka May 23 '19 at 12:31
  • The header is only tangentially related to your problem. An undefined function reference arises because the function *implementation* is not included in the link -- the appropriate object file or compiled library. This is already well explained by the dupe target. Since your makefile does not appear to have separate compile and link steps, you would need to name the appropriate object file or library in the one build rule it does have. It would probably be worthwhile to work out how to do the build by hand, without `make`, to inform how you fix the makefile. – John Bollinger May 23 '19 at 12:58

0 Answers0