Include path problem

Technical Support
, ,
1

The command for setting up the build environment,
“. /usr/local/oecore-x86_64/environment-setup-armv7at2hf-neon-angstrom-linux-gnueabi”
works as far as getting the right tools for cross compiling for the A7 processor.
However, when I try to compile code that I have been provided that has statements such as

#include <linux/xxxx.h>

(quotes provided to prevent this website from screwing up)
it finds the wrong include files. If I try to workaround the problem by fully qualifying the path to the correct include file in the linux-toradex include directory, it works for that one file, but then all the embedded includes such as:
"#include "
fail for the same reason. There has to be some way to tell the A7 cross compiler that I want to use the toradex linux files when in encounters these include statements.

2

Clearly there is no way to type what I want to type without this web site messing with it.

In the description above, everywhere you see #include, it is followed by a less than sign, the word linux then forward slash, then a filename, then the greater than sign.

3

Hi

It works here, e.g. the following c file provokes an error when compiling, as it redefines a type defined in a nested include:

#include <linux/types.h>
#include <stdio.h>

typedef char __kernel_long_t;

int main(void)
{
  printf("%i\n", sizeof(__kernel_long_t));
  return 0;
}

If compiled with the SDK environment sourced the gcc error output clearly states that the previous declaration stems from one of the nested include files from the sysroot:

> . /usr/local/oecore-x86_64/environment-setup-armv7at2hf-neon-angstrom-linux-gnueabi
> $CC hello.c -o hello
hello.c:4:14: error: conflicting types for ‘__kernel_long_t’
 typedef char __kernel_long_t;
              ^~~~~~~~~~~~~~~
In file included from /usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/include/asm/posix_types.h:35:0,
                 from /usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/include/linux/posix_types.h:35,
                 from /usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/include/linux/types.h:8,
                 from hello.c:1:
/usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/include/asm-generic/posix_types.h:14:15: note: previous declaration of ‘__kernel_long_t’ was here
 typedef long  __kernel_long_t;
               ^~~~~~~~~~~~~~~

The files are found because the compiler is passed the --sysroot parameter:

> echo $CC
arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi

Max

4

You happened to use which is defined in both your linux host system and in the toradex include files.
In my code I am trying to include rpmsg.h which is defined differently in the toradex include files than it is on my linux host machine. The toradex compiler is picking up the linux host version of the file because I am defining
struct rpmsg_device_dev;
which is defined in the toradex include but not on my host machine.

And if I try to work around the problem by fully qualifying the path where the toradex version of rpmsg.h resides, that works until inside rpmsg.h it encounters
#include (less than symbol) linux/device.h (greater than symbol)
and fails to find it.

So, how do I tell the toradex build system in general that the linux system files are in my toradex location rather than the host machine’s version of them?

5

What makes you think that some of the header files which the compiler reports to have included are provided by the build host’s distribution?

Could you provide a minimized example of your failing code along with how you source the SDK environment and how you call the compiler?

6

The imx_rpmsg_pingpong.c example calls rpmsg_send(). There is no prototype for rpmsg_send anywhere in /usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/local/linux.

But it does exist in the host system linux path inside rpmsg.h. Same with other rpmsg related structs and prototypes.

So, I’m having trouble compiling my program which makes rpmsg calls. There is documentation provided, rpmsg.txt, that describes User API calls including rpmsg_send. But these don’t work in a user program and ALL examples provided have them called from inside a LKM. SO, I’m guessing that somehow when compiling a LKM there are additional include paths that expose this call.

But, I’m writing code that is intended to run as an application, not as one big LKM, so my code doesn’t compile whereas the ping pong LKM compiles. I had previously asked a question about trying to leverage an LKM where I could use open,close,read,write to call into an rpmsg LKM to do what needs to be done, but there are no examples that show how to do that. There is a TTY example with open,close,write, (no read), which is very specific to being a TTY but I simple want to send a block of data across rpmsg to the M4 processor and get a block of data back and there are, surprisingly, no examples for doing that, and I cannot write a user application that calls rpmsg_send directly because the interface is not exposed.

7

The imx_rpmsg_pingpong.c example is a kernel driver, which needs to run inside the kernel! You cannot run that from user space. There is not user space rpmsg API…

If you really need a rpmsg API from user space, you have to use the rpmsg-sysfs kernel module, as I mentioned in the A generic way to make use of rpmsg from user space question.