【问题】
之前已经折腾完毕：
【记录】Ubuntu下使用Eclipse编译一个基于makefile的C项目
期间，也解决过类似的N多问题：
【已解决】Eclipse通过Makefile调用交叉编译器交叉编译C项目出错：Type ‘FILE’ could not be resolved
【已解决】Eclipse中交叉编译C项目出错：Symbol ‘SETVAL’ could not be resolved
【已解决】Ubuntu下Eclipse中交叉编译C项目出错：Symbol ‘NULL’ could not be resolved
【已解决】Ubuntu下Eclipse中交叉编译C项目出错：Symbol ‘off’ could not be resolved
但是此处，虽然没有编译那个BSP中的Uboot，但是Eclipse由于找不到对应的结构体变量，结果还是报错：
Description Resource Path Location Type |
如图：
【解决过程】
1.很明显，是找不到immap_t的定义。
2.去找immap_t，参考：
看到都是ppc的。
且看到头文件是：
3.参考：
accessing immap_t * variable in mpc8260
和
[U-Boot-Users] [PATCH 04/18] Stop using immap_t for guts offset on 85xx
知道了mpc中也是。
好像是ppc和mpc是同一个东西，即ppc是机构，mpc是板子？
4.参考：
[U-Boot] [PATCH] I2C: Fix CodingStyle issues in soft_i2c.c
其是一个patch，真的是soft_i2c.c
但是其中的代码，和此处得很类似：
volatile immap_t *immap = (immap_t *) CFG_IMMR;
...
uint dpalloc (uint size, uint align)
{
...
volatile immap_t *immr = (immap_t *) CFG_IMMR;
...但是此处没有添加任何define。
5.然后后来在：
/HART-IP/BSP/Bootloader/u-boot-1.1.4-whgs/examples/Makefile
中看到了对应的配置：
# The following example is 8260 specific... ifeq ($(CPU),mpc8260) SREC += mem_to_mem_idma2intr.srec BIN += mem_to_mem_idma2intr.bin mem_to_mem_idma2intr endif
即， 只有定义了mpc8260，才会用上此代码，所以，此处为了让Eclipse对于此代码不报错，那就随便添加一个宏判断吧，比如：
#ifdef CPU //ifeq ($(CPU),mpc8260) ...... #endif //#ifdef CPU //ifeq ($(CPU),mpc8260)
而把所有的代码，都变成#ifdef中内容了，
而由于Eclipse无法判断宏（CPU）是否被定义，所以就不会再去判断其中的内容，也就不会报错了：
此处，当真正的定义了CPU，且其值是mpc8260，则对于文件：
mem_to_mem_idma2intr.c
也是可以被正常编译了，所以之前加的ifdef也不会影响到文件的编译的。
【总结】
此处，Eclipse对于C代码报错：
Type ‘immap_t’ could not be resolved
其根本原因是：
此处的c文件mem_to_mem_idma2intr.c中包含了此处定义，那是因为
在makefile中，都通过宏去判断了，当：
ifeq ($(CPU),mpc8260)
时，才会编译此文件。
而Eclipse无法识别makefile中的这种判断，导致始终会去解析此文件，而找不到对应头文件，而报错。
所以，此处为了去掉此Eclipse的"误报"，直接去加了个
#ifdef CPU //ifeq ($(CPU),mpc8260) ...... #endif //#ifdef CPU //ifeq ($(CPU),mpc8260)
而暂时规避了此问题。
转载请注明：在路上 » 【已解决】Ubuntu下Eclipse中交叉编译一个C项目出错：Type ‘immap_t’ could not be resolved