S3C2416裸机开发系列十四_GCC下UCGUI的移植(2)

2016-12-12 来源：eefocus

现在主要讲解一下在GCC移植UCGUI，Makefile工程如何加入目录，加入源码，c标准库，编译选项的设置。

笔者的Makefile模板提取自uboot，工程中加入目录，加入源码都是很简单的，详细的介绍请参考前面章节” GCC启动代码工程应用实例”。下面主要介绍UCGUI目录下很多的源码文件Makefile的编写，一种可行的方式就是把GUI目录上所有的c文件，不管有无用到，均加入工程进行编译，第一次编译时间较长，但以后不用重复编译。因此这部分的Makefile实现如下：

include $(TOPDIR)/config.mk

SRCS := $(wildcard *.c)$(wildcard *.C)

OBJS := $(SRCS:.c=.o)$(SRCS:.C=.o)

CURDIR := $(shell pwd)

FOLDER := $(notdir $(CURDIR))

LIB := lib$(FOLDER).a

.PHONY: all clean

all: .depend $(LIB)

$(LIB): $(OBJS)

@$(AR) $(ARFLAGS) $@ $(OBJS)

clean:

rm -f .depend *.o $(LIB)

#########################################################################

# defines$(obj).depend target

include$(TOPDIR)/rules.mk

sinclude .depend

#########################################################################

把这个Makefile模板加入到GUI下所有的子目录和GUIDemo目录中，其它目录的Makefile也类似编写加入，这样即可把所有要编译的源码加入工程。每个子目录的Makefile需加入该目录下要编译的源码文件，生成该目录下的源码依赖关系文件.depend，最终生成该目录下的静态库文件，以供顶层目录的Makefile链接输出相应的可执行代码文件，工作方式与uboot是完全一致的。

修改顶层目录的Makefile，加入各个子目录Makefile的路径，以调用编译该目录下的源码。子目录路径SUBDIRS变量的修改如下:

SUBDIRS = $(TOPDIR)/start_code $(TOPDIR)/apps

SUBDIRS += $(TOPDIR)/GUI/AntiAlias $(TOPDIR)/GUI/ConvertColor \

$(TOPDIR)/GUI/ConvertMono $(TOPDIR)/GUI/Core \

$(TOPDIR)/GUI/Font $(TOPDIR)/GUI/LCDDriver \

$(TOPDIR)/GUI/MemDev $(TOPDIR)/GUI/MultiLayer \

$(TOPDIR)/GUI/Widget $(TOPDIR)/GUI/WM

SUBDIRS += $(TOPDIR)/GUI_X $(TOPDIR)/GUIDemo

修改顶层目录的config.mk，对编译选项如-O2二级编译优化或-g加入调试等进行设置，此处需加入工程c编译器的头文件的搜索路径，对于UCGUI头文件搜索路径只需加入Config、GUI/Core、GUI/Widget、GUI/WM这四个目录路径即可。头文件搜索路径CFLAGS变量的修改如下，s3c2416没有硬件浮点单元，加-msoft-float防止配置成只支持硬浮点的交叉工具通过编译。

CFLAGS := -Wall -Wstrict-prototypes -mcpu=arm920t -msoft-float

CFLAGS += -I $(TOPDIR)/start_code -I$(TOPDIR)/apps

CFLAGS += -I $(TOPDIR)/GUI/Core -I$(TOPDIR)/GUI/Widget \

-I $(TOPDIR)/GUI/WM -I $(TOPDIR)/Config

CFLAGS += -I $(TOPDIR)/GUIDemo

设置库，嵌入式开发很大程度上依赖于标准c库。在linux操作系统下，标配的c库为glibc，glibc囊括了几乎所有的UNIX通行标准，可见其内容包罗万象。因此glibc对于很多嵌入式系统来说过于臃肿和庞大，并且很多函数严重依赖于linux的系统调用。笔者在较老版本交叉编译工具开发裸机代码，可以链接glibc，但新版本的工具却无法顺利链接glibc。为了解决glibc在嵌入式应用中的不足，很多面向嵌入式的c标准库已经被开发出来，如uclibc、newlib、eglibc等。这些嵌入式c库特点就是比glibc小很多，相对独立，可不需要操作系统支持，不支持glibc的完整实现，很多功能可以根据空间需求进行取舍。一般开发linux系统，可以用glibc，如果对代码容量等方面有要求，也可使用嵌入式c库。笔者测试用相同的UCGUI移植代码分别链接uclibc和glibc，代码容量差距相当明显，链接uclibc时，可执行代码只有270k，而glibc达到700k。此处采用uclibc作为c库，对于在linux下做开发而采用glibc的读者，可以下载uclibc的最新源码库，通过make menuconfig简单配置，用交叉编译工具编译源码库，即可生成交叉编译工具可使用的c库。嵌入式开发最常使用到字符处理、数学处理方面的库函数，非linux操作系统开发，只能链接静态库，在linux下对应库名为libc.a和libm.a。由于不使用glibc，因此标准c库应指定uclibc的库存放路径。同时，对于没有硬件除法器，浮点处理单元的arm，对取余和除法操作，浮点处理都需要libgcc.a的支持。UCGUI移植用到了这三个库，因此需要在Makefile中指定这三个库的路径，库路径设置如下，对于uclibc中的libc.a和libm.a库路径，需要读者根据自己的嵌入式库路径进行修改。

PLATFORM_LIBS :=

# 加入uclibc标准c库以及数学函数库

PLATFORM_LIBS += -L /opt/crosstool/uClibc-0.9.33.2/lib -lm -lc

# 加入gcc库

PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS)-print-libgcc-file-name`) –lgcc

至此，Makefile工程设置完毕，跳转到顶层目录，执行make即可开始编译工程。编译时产生一大堆错误，主要是提示头文件未找到，micrium给出的GUIDemo目录下的测试代码写的不够严谨，源代码中include头文件名不区分大小写。例如实际要#include“GUI.h”，但有些源码中是#include'GUI.H'，这对于windows来说是没有区别的，因为windows文件系统不区分大小写，但linux却是区分大小的，因此会提示找不到文件。windows操作系统假定它的用户是儿童，对一般用户来说，apple和Apple都是苹果，没有区别。但linux/unix操作系统假定它的用户是专业人士，apple和Apple虽然都是苹果，但它们的大小、产地、口感等均是不同的，因此是有区别的。为了代码的可重用，这些问题都是需要注意的，尤其是同时在windows和linux下做开发，应保证一定的规范性。如在windows下文件目录名区分大小写，在linux下文件名加后缀(如.c、.h)表示这个文件的用途等。此处没有好的方法，只能修改GUIDemo下所有不区分头文件名大小写的源码。