WinCE中sources文件中targetlibs与sourcelibs的作用与区别

[原创] WinCE中sources文件中targetlibs与sourcelibs的作用与区别[复制链接] wwfiney 当前离
线
最后登录2011-12-23 在线时间488 小时权威
71
金币
1455
注册时间2009-2-9 阅读权限200
帖子
1286
精华
4
积分
1707
UID
86
管理员
权威
71
金币
1455
阅读权限200
积分
1707
精华
4 电梯直达
主题贴
wwfiney 发表于2009-2-11 17:23:04 |只看该作者|倒序浏览
在WinCE里面，编译和链接的必备文件sources，做过WinCE BSP开发的一定都很熟悉，其中有2个关键字，targetlibs和sourcelibs，一直让我对其中的区别很感兴趣，故查阅了一些资料，与大家分享。

其实只要搜索以下就会得到一些基本的答案，比如：
TARGETLIBS，如果一个库以DLL的形式提供给调用者，就需要用TARGETLIBS，它只链接一个函数地址，系统执行时会将被链接的库加载。

比如coredll.lib就是这样的库文件。

即动态链接。

SOURCELIBS，将库中的函数实体链接进来。

即静态链接，用到的函数会在我们的文件中形成一份拷贝。

这个答案已经基本解决问题了，但是这个答案让我们能看到更深入的东西：
This is componentization feature of Windows CE.
The link has two steps. First, whatever is in SOURCELIBS gets combined in a
signle library yourproductname_ALL.lib. In the second step, executable module is linked from that library and all the targetlibs.
This is done to allow stubs to be conditionally linked: if the function is defined into your source already, stubs get excluded. If it is not there, stubbed version (returning ERROR_NOT_IMPLEMENTED or something to that
effect) gets linked in instead.
If the link were to be performed in just one step, it would be impossible to predict which version (real or stub) would get included. As it is, implemented functions have a priority over stubs.
--
Sergey Solyanik
Windows CE Core OS
总的来说就是先编译了你自己在sources里指定的源文件，在链接阶段，先将所有的sourcelibs链接在一起成为一个lib，然后与targetlibs指定的lib一起参与链接。

当然这里targetlibs指定的可以是dll的lib文件，在CE的帮助文件中，
帖子1286
串个门加好友打招呼发消息有说明targetlibs可以使用import libraries or static libraries。

但是sourcelibs说明中指出一般用在把许多小的lib合并为一个大的lib。

还有关于用法的一些说明：
EXEs
Only TARGETLIBS get linked, anything in SOURCELIBS is ignored DLLs
SOURCELIBS and TARGETLIBS get linked, in that order
LIBs
Only SOURCELIBS get linked, anything in TARGETLIBS is ignored
Google groups 上Steve Maillet一直在回答相关的问题，并且强调只是一些link的顺序问题，可以参看makefile.def。

为了把问题弄清楚，看了下makefile.def因为很少接触makefile文件，所以凭有限的makefile知识，来解读下（MS的全自动化编译工具害人啊）
注：由于对makefile了解有限，如果分析有错误的地方请大家指出1. 关于LIBS的link
!IF "$(TARGETTYPE)" == "LIBRARY"
$(_RELEASELIBDIR)\$(TARGETNAME).lib: $(TARGETOBJFILES) $(SOURCELIBS)
@echo BUILD_MARKER:LINK_STATIC_LIBRARY_START Linking $@
$(LIBRARIAN) -out:$(_RELEASELIBDIR)\$(TARGETNAME).lib $(MACHINEOPTION) @<<
-ignore:4001
$(LIBDEFINES)
-nologo
-nodefaultlib
$(LINKER_SUBSYSTEM)
$(TARGETOBJFILES)
$(SOURCELIBS)
<<NOKEEP
2. 关于DLL
有些条件判断，但是链接顺序都是
$(TARGETOBJFILES)
$(SOURCELIBS)
$(TARGETLIBS)
3. 关于EXE
$(TARGETOBJFILES)
$(TARGETLIBS)
$(SOURCELIBS)
由此对
EXEs
Only TARGETLIBS get linked, anything in SOURCELIBS is ignored 产生了一些质疑
关于链接顺序：
在我的印象里，应该是出现同样的symbol，优先链接第一个出现的（查了半天也没有找到文档作为证明，不过我用bcc试了一下，默认是链接第一个出现的）。

这样就说明了链接顺序带来的影响，比如你的源文件里有一个func 这个函数的实现，但是在sourcelibs里包含的func1.lib里面也有同样函数的实现，这时候会使用你的源文件里面的func实现，而不是func1.lib 里面的，同样对应于targetlibs
这样做可以使用一些stub，比如KITL.c在BSP的两个地方实现Src\Kernel\Kern和Src\Kernel\Oal，而kern下的就是个stub，里面什么也没做，用来关闭KITL功能，OAL下的才是功能实体，在链接过程中，kern下使用TARGETLIBS来引入oal.lib，但是OAL下KITL.c里面的函数实现都已经被kern下的KITL.c替换了，这个生成的kern.exe 后续会在common.bib里面被加入NK.exe(关闭KITL的时候)。

而Src\Kernel\Kernkitl下生成的kernkitl.exe也引入了oal.lib，由于自身没有KITL的实现函数，所以实现代码就是OAL里面的代码，在打开KITL的时候就会加入NK.exe。

以下是common.bib的关于KITL的片断：
IF IMGNOKITL。