当前位置首页 > 百科> 正文

lib

2019-09-16 00:20:40 百科
lib

lib

LIB有两种,一种是静态库,比如C-Runtime库,这种LIB中有函式的实现代码,一般用在静态连编上,它是将LIB中的代码加入目标模组(EXE或者DLL)档案中,所以连结好了之后,LIB档案就没有用了。一种LIB是和DLL配合使用的,里面没有代码,代码在DLL中,这种LIB是用在静态调用DLL上的,所以起的作用也是连结作用,连结完成了,LIB也没用了。至于动态调用DLL的话,根本用不上LIB档案。 目标模组(EXE或者DLL)档案生成之后,就用不着LIB档案了。

基本介绍

  • 外文名:library
  • 属于:一种是静态库
  • 比如:C-Runtime库
  • 包含:一般用在静态连编上

单词解释

  • n. 图书馆;藏书室;【计算机】(程式)库,档案库

打开方法

用程式语言,打开lib档案的办法有三个:
1、在object/library modules使用全路径名;
2、把*.lib放在VC的Lib目录中
3、修改project setting的Link->Input中的Addtional library path,加入你的目录。

载入方法

1.LIB档案直接加入到工程档案列表中
在VC中打开File View一页,选中工程名,单击滑鼠右键,然后选中\"Add Files to Project\"选单,在弹出的档案对话框中选中要加入DLL的LIB档案即可。
2.设定工程的 Project Settings来载入DLL的LIB档案
打开工程的 Project Settings选单,选中Link,然后在Object/library modules下的文本框中输入DLL的LIB档案。
3.通过程式代码的方式
加入预编译指令#pragma comment (lib,"路径\*.lib"),这种方法优点是可以利用条件预编译指令连结不同版本的LIB档案。因为,在Debug方式下,产生的LIB档案是Debug版本,如Regd.lib;在Release方式下,产生的LIB档案是Release版本,如Regr.lib。
当应用程式对DLL的LIB档案载入后,还需要把DLL对应的头档案(*.h)包含到其中,在这个头档案中给出了DLL中定义的函式原型,然后声明。

档案

Lib格式只有四种类型的节(Section),即First Sec,Second Sec,Longname Sec和Obj Sec;其中Second Sec与Longname Sec是可选节,很多Lib档案中都没有。而开头的Singature只是一个标识,它相当于COFF目标档案中的魔法数字。它是一个长度为8的字元串,值为“!<arch>\n”。
First Sec,顾名思义,就是第一个节。它包含了库中所有的符号名以及这些符号所在的目标档案在库中的位置(绝对偏移)。
Second Sec就是第二节。它的内容和First Sec是相同的。不同的是,Second Sec是一个有序表,通过它来查找库中的符号比通过First Sec来查找要快很多。
Longname Sec是长名称节。这一节是一个字元串表。它包含了所有长目标档案名称。如果后面的Obj Sec中没有给出相应的目标档案名称,我们就要到这一节中来查找。
Obj Sec就是目标档案节。这些节中存储着不同的目标档案的原始数据。
在库档案中,每一节都有两个部分。一个部分是头,另一个部分才是该节的数据;数据紧跟在头的后面。头描述了该节数据的类型、长度等信息。这些头的格式都是相同的。其结构用C语言描述如下:
typedef struct {
char Name[16]; // 名称
char Time[12]; // 时间
char UserID[6]; // 用户ID
char GroupID[6]; // 组ID
char Mode[8]; // 模式
char Size[10]; // 长度
char EndOfHeader[2];// 结束符
} SectionHeader;
可以看到,头中的数据全都是字元串。用字元串的好处是可以提高格式的兼容性,因为在不同的机器上,数据的排列方式是不同的。有的机器是以Little-Endian方式工作,还有的是以Big-Endian方式工作,它们互不兼容(这两种方式的区别!?请看我的《COFF格式》一文,其中的档案头一节有说明)。用字元串就不会有这种问题(后面我们将会遇到)。但它也有不方便的地方,就是必须把字元串转换成数值,多了一个步骤。
在这个结构中,最常用的Name、Size以及EndOfHeader三个成员。Name就是节的名称啦!Size也很好理解,就是该节数据的长度。要注意的就是这个EndOfHeader成员了!这个成员标誌着头的结束,其内容为“`\n”(注意,这里没有打错,是两个字元“`”和“\n”)。怎幺样?有点奇怪吧?为什幺要有这个结束符?每一节的头长度一定,每节中的数据长度也知道。按顺序向下读不行吗?答案是:不行!因为每一节之间存在间隙!通常是一个位元组或零个位元组。如果是零个位元组倒好,按顺序向下读是OK的。可是如果不为零的话,这样读就要错位了。要知道错位没有,只好用一个结束符来定位了。如果在读头的时候发现结束符不对,那就要一个位元组一个位元组地向下查找,直到找到结束符,才能算是对齐了。切记!切记!
当然,通过First Sec或Second Sec中给出的偏移来读数据就不存在这个问题。不会发生错位,放心读吧!
让我们来看看每一节中的数据是什幺样子。
First Sec
第一节,通常就是Lib中的每一个小节。它的名称是“/”。其数据部分的结构如下:
typedef struct {
unsigned long SymbolNum; // 库中符号的数量
unsigned long SymbolOffset[n]; // 符号所在目标节的偏移
char StrTable[m]; // 符号名称字元串表
}FirstSec;
第一个成员SymbolNum是符号的数量。注意!它是以Big-Endian方式储存的(x86平台上的数据是以Little-Endian方式储存的。这里应该注意转换。后面给出的convert函式可以在Little-Endian格式与Big-Endian格式之间进行相互转换)。
第二个成员SymbolOffset是一个数组,它的长度n就是符号的数量,也就是SymbolNum。这个数组储存了每一个符号所在的目标节的偏移。我们可以方便地通过它来查找符号所在的目标档案。注意!它也是以Big-Endian格式储存的。
第三个成员StrTable是一个字元串表,它的长度m就是SectionHeader.Size的值减去(SymbolNum+1)*4。其结构很简单,就是一堆以‘\0’结尾的字元串(和COFF档案中的字元串表结构相同)。在有的系统中,它还可能是以“/\n”这两个字元结尾的字元串的集合。
很简单的一个结构,不过有两个成员的长度是不定的。怎幺才能方便地从Lib中读出这些数据,留给大家自己想吧!下面我只给出一个进行Little-Endian与Big-Endian互转的函式。
inline void convert(void * p // 要转换的数据的指针
,size_t size = 4 // 数据的长度,long为4,short为2
) {
char * buf=(char*)p;
char temp;
for ( size_t i=0;i<size/2;i++ ) {
temp=buf[i];
buf[i]=buf[size-i-1];
buf[size-i-1]=temp;
}
}
Second Sec
第二节
这一节与第一节很相似!它通常也就是Lib档案的第二个节。它的名字也是“/”(注意:档案中第一个叫“/”的节是第一节,第二个就是第二节)。不过它的结构与第一节有些不同,如下:
typedef struct {
unsigned long ObjNum; // Obj Sec的数量
unsigned long ObjOffset[x]; // 每一个Obj Sec的偏移
unsigned long SymbolNum; // 库中符号的数量
unsigned short SymbolIdx[n]; // 符号在ObjOffset表中的索引
char StrTable[m]; // 符号名称字元串表
}SecondSec;
第一个成员ObjNum是库中Obj Sec的数量。
第二个成员ObjOffset是一个偏移表,它记录了库中所有Obj Sec的偏移。这个表的记录数x就是ObjNum。
第三个成员SymbolNum与First Sec中的SymbolNum意义相同。
第四个成员SymbolIdx变成了一个索引,它记录了相应名称字元串在ObjOffset这个表中的位置,我们要通过两次索引才能找到我们所要符号的Obj Sec位置。它的项目数n为SymbolNum。但请注意,这个索引是unsigned short型,不再是unsigned long型。
第五个成员StrTable结构与First Sec中的一样。不过,它的长度m为SectionHeader.Size的值减去((ObjNum+1)*4+(SymbolNum+2)*2)。
值得注意的是,这里的所有数据都是Little-Endian格式的。千万不要弄错了!Longname Sec
这个小节就是一个字元串表,它的名称为“//”,其结构同FirstSec.StrTable。这里就不多说了。
Obj Sec
这一节中的数据就是COFF档案的原始数据,把它读出来存成档案,就是一个COFF档案。它的格式请参考《COFF格式》一文。
要指出的是它的命名方式有些特殊。如果Obj档案的名称少于16个字元,它就会被保存在SectionHeader的Name成员中,以‘/’字元结尾。如果无法保存在Name成员中,则Name成员的第一个字元就为‘/’,之后再跟上这个名称在Longname Sec中的偏移。
例如:
!<arch>\n
……
LongName Sec:
This_Is_Long_Name0001\0
This_Is_Long_Name0002\0
……
Obj Sec1:
Name[16]:“shortname/”
……
Obj Sec2:
Name[16]:“/0” // 这里使用了第一个长档案名称This_Is_Long_Name0001
……
Obj Sec3:
Name[16]:“/22” // 这里使用了第二个长档案名称This_Is_Long_Name0002

含义

在新能源产业领域,LIB是指液体锂离子电池(Lithium Ion Battery),液态锂离子电池是指 Li +嵌入化合物为正、负极的二次电池。正极採用锂化合物LiCoO2或LiMn2O4和LiFePO4,负极採用锂-碳层间化合物,电解质是液体的六氟磷酸锂。锂离子电池由于工作电压高、体积小、质量轻、能量高、无记忆效应、无污染、自放电小、循环寿命长,是21世纪发展的理想能源。

标记信息库

LIB(label Information Base) ,标籤信息库
对路由表中的每一条IGP的IP前缀来说,第一台LSR都会进行本地捆绑,也就是说,为IPv4前缀捆绑标籤。然后LSR再将该捆绑的标籤分发给所有LSP邻居。这些接收到的标籤转换为远程标籤。之后邻居将该远程和本地标籤存储于一张特殊的表中,这张表就是标籤信息库(LIB)。
lib
声明:此文信息来源于网络,登载此文只为提供信息参考,并不用于任何商业目的。如有侵权,请及时联系我们:baisebaisebaise@yeah.net