CODEWITHSUNDEEP
ccross-compilingembedded-linuxeclipse-cdt
Ed King
Ed King

Reputation: 1863

How to get Eclipse CDT to use the correct Linux headers and stop throwing semantic errors?

There are many different answers circling around this topic, but I think my problem might be a bit more specific, as none work.

I am using Eclipse (v3.8.1) to build a C application for an embedded target. I use LTIB to build the target image, and I have been able to confirm that the GCC toolchain provided by LTIB (for a Freescale i.MX processor) is sound - I can successfully build and deploy a "Hello World" application to the target.

Now I'm trying to include some Linux headers for the target in Eclipse. So, I add a VAR to ${LTIB_LOC} = /home/user/ltib in Eclipse and add the include file directories everywhere seemingly imaginable (with help from other answers).

${LTIB_LOC}/rpm/BUILD/linux-2.6.31/include

And in the source code, I add the headers I need:

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

Now, the problem is two-fold. Firstly, the common header types.h is being picked-up from the built-in host directories (/usr/include/linux), whereas I want to use the ones in the LTIB directories. Secondly, the custom i.MX header imx_types.h cannot be found by the Eclipse discovery scanners, so I have persistent semantic warnings/errors, even though the compiler can find the headers and the project builds.

How can I get rid of the built-in host directories so that I always use the target Linux headers, and how do I get rid of the incredibly annoying semantic errors?

Upvotes: 0

Views: 405

Answers (1)

HighCommander4
HighCommander4

Reputation: 52799

You need to configure your built-in compiler settings provider to find the correct toolchain.

Go to Project Properties | C/C++ General | Providers. Select [Your Toolchain] Built-in Compiler Settings, and in the Command to get compiler specs, replace ${COMMAND} with the path to your cross-compiler.

This should get CDT to stop picking up the built-in includes of the system's default toolchain, and start picking up the built-in includes of your cross-compiler toolchain.

(Yes, replacing ${COMMAND} with an explicit path is hacky. The proper way to do this, at least in the minds of the developers who designed this system, is to have the cross-compiler's developers distribute an Eclipse plugin that defines its own [Cross Compiler Name] Built-in Compiler Settings provider, which knows where the compiler executable is (i.e. for which ${COMMAND} is the right thing to begin with), and use that instead of the default built-in settings provider. I assume you do not have such an Eclipse plugin handy.)

Upvotes: 1

Related Questions