Roles and differences between targetlibs and sourcelibs in the sources file in WinCE

In wince, the necessary file sources for compiling and linking must have been familiar with the development of Wince BSP. There are two keywords: targetlibs and sourcelibs, I have been very interested in the differences, so I have read some materials and shared them with you.
   In fact, you only need to search for the following basic answers, such:

Targetlibs: If a library is provided as a DLL to the caller, you need to use targetlibs. It only links to one function address, and the Linked Library will be loaded during system execution. For example, coredll. Lib is such a library file. Dynamic Links.

Sourcelibs: link function entities in the library. That is, static links. The functions used form a copy in our files.

This answer has basically solved the problem, but it allows us to see more in-depth things:
This is componentization feature of Windows CE.
The link has two steps. First, whatever is in sourcelibs gets combined in
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 synchronized med in just one step, it wocould be impossible
Predict which version (real or stub) wocould get pinned ded. As it is,
Implemented functions have a priority over stubs.
--
Sergey solyanik
Windows CE core OS

In general, the source files specified in sources are compiled first. In the link stage, all sourcelibs files are linked together to form a Lib, then join the link with the Lib specified by targetlibs.

Of course, the targetlibs can be the DLL lib file. In the CE help file, it indicates that targetlibs can use import libraries or static libraries. However, the sourcelibs description indicates that many small lib libraries are generally combined into a large Lib.

There are also instructions on usage:

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

 

On Google groups, Steve Maillet has been answering related questions and stressed that it is only some link sequence problems. For more information, see makefile. Def.

 

In order to clarify the problem, I read makefile. Def, which has little access to makefile files, so I will explain it with limited makefile knowledge (MS's fully-automated compilation tool is harmful)

Note: Due to your limited understanding of makefile, if there is any error in the analysis, please point out

1. Link of libs

   ! 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

   We can see that targetlibs is ignored.

2. About DLL
   Some conditions are determined, but the link order is
   $ (Targetobjfiles)
   $ (Sourcelibs)
   $ (Targetlibs)

3. About exe
   $ (Targetobjfiles)
   $ (Targetlibs)
   $ (Sourcelibs)

Therefore
Exes
   Only targetlibs get linked, anything in sourcelibs is ignored
Some questions have been raised.

About the link sequence:

   In my impression, the same symbol should appear, and the first one appears in priority links (I haven't found any documentation for a long time, but I tried it with BCC, the first link appears by default ).

   This illustrates the impact of the link sequence. For example, you have a func function in the source file, but the same function is also implemented in func1.lib contained in sourcelibs, at this time, you will use the func implementation in your source file, instead of the func1.lib, which also corresponds to targetlibs.

   In this way, Stub can be used. For example, kitl. c implements SRC \ kernel \ Kern and SRC \ kernel in two places of BSP (when kitl is disabled ). SRC \ kernel.

   The following is a section about kitl of common. bib:

   If imgnokitl
      Nk.exe        $ (_ Flatreleasedir) \ kern.exe               NKShxl
   Endif imgnokitl
   If imgnokitl!
      Nk.exe        $ (_ Flatreleasedir) \ kernkitl.exe           NKShxl
   Endif imgnokitl!

 

This explains how the kitl switch works (close at build Layer)

 

From the above description, can we draw the following conclusions:

1. targetlibs is not used for libs. For DLL and exe, the link sequence is different.

2. Be careful about the overwrite relationship of the same function when building DLL and exe.