1. gcc头文件包含,动态链接库
1、包含哪个头文件,需要查询程序使用库的SDK说明文档,比如printf(),它的函数声明在stdio.h头文件中,因此要使用printf(),必须在开头加上一句:
#include <stdio.h>
2、动态链接库,这个是从静态链接库发展而来的,所谓库即很多程序都会使用的代码,因此程序员提取出来,称之为库,最早的库是静态库,所谓静态即表示在生成可执行文件的链接阶断,链接器会将程序所需要的库文件,和程序的文件一起打包为一个文件。这会使得应用程序很大,不仅不利于存储而且操作系统加载时也会耗费时间,因此才引入了动态库,动态库只会在链接阶断生成程序时,加入一小段数据,用于描述此程序使用了哪此库,使用了库中的哪些函数,以及这些函数的虚拟内存地址。
2. VC程序调用动态库,编译时候也跟着编译动态库
不太清楚你的工程是如何建立的,想必一个工程是生成动态链接库,另一个是调用程序EXE了。由于VC动态库有两种形式,Regular和Extended两种,其中一种能导出类,另一种只能导出变量和函数。如果导出的是类,你在编译EXE文件时自然需要用到类得声明文件,即你前面所说的动态库本身所引用的文件。如果导出的是函数或变量,有可能出现的情况是:一般为了代码的重用性,把需要导出的函数或变量单独放在一个头文件中,用一个宏控制其导入、导出。编译动态库时,宏定义为导出,编译EXE时,宏变为导入,这个头文件为两者共用。如果不小心在这个头文件中包含了其他头文件,也可能出现你说的情况。如果动态库调用直接采用函数入口地址的方法,则什么都不用声明,当然,只适用于导出函数与变量的情形。
3. 如何编译动态库,该动态库需要链接另外一个动态库
看你的makefile, 猜测是没有指定动态库头文件的路径. -I编译参数来指定
4. 我在一个机器上编了个动态库,在另一个机器上编译了一个引用这个动态库的可执行程序,能调用不
什么语言?C++还是C#?Native还是managed?
一般是没有问题的,只要保证:
1、你这个动态库没有依赖其他动态库(包括系统的、MFC的、CRT的、VC的、或者.NET Framework的),或者依赖的其他动态库在另一台机器上也都有;
2、而且不存在32位和64位的兼容问题(即动态库以及可执行程序都是32位的或者都是64位的,而且操作系统也不存在这个兼容性的差异);
3、可执行程序连接动态库使用的LIB文件和动态库是匹配的(如果是native的)
____________________
补充:
哦~~~ Linux我是门外汉了,那就看看其他朋友有没有Linux大拿帮忙回答一下吧……
5. 如何在vc中使用mingw编译出来的动态库和静态库
mingw编译出来的静态库后缀名为.a,编译出来的动态库的导入库后缀名为.dll.a,而在windows下后缀名为.lib的库可能是静态库也可能是动态库的导入库。
mingw编译出来的动态库的导入库可以直接在vc中直接使用,例如
#pragma comment(lib, "libx264.dll.a")
这样你就不需要生成一个.lib后缀的动态库的导入库了,网上也有如何从.dll生成.lib的方法。
如果链接了动态库的导入库libpthread.dll.a,你发布的应用程序就要带上pthread的dll。
使用静态库的好处是发布的应用程序组件模块里不需要带上相关的dll,如果要使用mingw编译出来的静态库,可以如下:
#pragma comment(lib, "libx264.a")
但是仅仅链接这么一个静态库是不够的,你还需要链接
libgcc.a
libmingwex.a
你可能还需要链接libmsvcrt.a
否则会报一堆错误:error LNK2001: 无法解析的外部符号
上面的这些库在C:\MinGW\lib目录或子目录下面可以找到。
链接这些库的原因是mingw使用的gcc编译器和vc编译器之间存在差异
6. 动态库的编译
生成动态连接库,假设名称为libtest.so
gcc x.cy.cz.c-fPIC-shared-olibtest.so
将main.c和动态连接库进行连接生成可执行文件
gcc main.c-L.-ltest-omain
输出LD_LIBRARY_PATH环境变量,以便动态库装载器能够找到需要的动态库
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
测试是否动态连接,如果列出libtest.so,那么应该是连接正常了
ldd main
7. 三:构建静态库与动态库 及 如何使用外部共享库和头
我们通常把一些公用函数制作成函数库,供其它程序使用。
函数库分为静态库和动态库两种。
静态库在程序编译时会被连接到目标代码中,程序运行时将不再需要该静态库。
动态库在程序编译时并不会被连接到目标代码中,而是在程序运行是才被载入,因此在程序运行时还需要动态库存在。
本文主要通过举例来说明在Linux中如何创建静态库和动态库,以及使用它们。
在创建函数库前,我们先来准备举例用的源程序,并将函数库的源程序编译成.o文件。
第1步:编辑得到举例的程序--hello.h、hello.c和main.c;
hello.h(见程序1)为该函数库的头文件。
hello.c(见程序2)是函数库的源程序,其中包含公用函数hello,该函数将在屏幕上输出"Hello XXX!"。
main.c(见程序3)为测试库文件的主程序,在主程序中调用了公用函数hello。
程序1: hello.h
#ifndef HELLO_H
#define HELLO_H
void hello(const char *name);
#endif //HELLO_H
程序2: hello.c
#include
void hello(const char *name)
{
printf("Hello %s!/n", name);
}
程序3: main.c
#include "hello.h"
int main()
{
hello("everyone");
return 0;
}
第2步:将hello.c编译成.o文件;
无论静态库,还是动态库,都是由.o文件创建的。因此,我们必须将源程序hello.c通过gcc先编译成.o文件。
在系统提示符下键入以下命令得到hello.o文件。
# gcc -c hello.c
#
(注1:本文不介绍各命令使用和其参数功能,若希望详细了解它们,请参考其他文档。)
(注2:首字符"#"是系统提示符,不需要键入,下文相同。)
我们运行ls命令看看是否生存了hello.o文件。
# ls
hello.c hello.h hello.o main.c
#
(注3:首字符不是"#"为系统运行结果,下文相同。)
在ls命令结果中,我们看到了hello.o文件,本步操作完成。
下面我们先来看看如何创建静态库,以及使用它。
第3步:由.o文件创建静态库;
静态库文件名的命名规范是以lib为前缀,紧接着跟静态库名,扩展名为.a。例如:我们将创建的静态库名为myhello,则静态库文件名就是libmyhello.a。在创建和使用静态库时,需要注意这点。创建静态库用ar命令。
在系统提示符下键入以下命令将创建静态库文件libmyhello.a。
# ar cr libmyhello.a hello.o
#
我们同样运行ls命令查看结果:
# ls
hello.c hello.h hello.o libmyhello.a main.c
#
ls命令结果中有libmyhello.a。
第4步:在程序中使用静态库;
静态库制作完了,如何使用它内部的函数呢?只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明静态库名,gcc将会从静态库中将公用函数连接到目标文件中。注意,gcc会在静态库名前加上前缀lib,然后追加扩展名.a得到的静态库文件名来查找静态库文件。
在程序3:main.c中,我们包含了静态库的头文件hello.h,然后在主程序main中直接调用公用函数hello。下面先生成目标程序hello,然后运行hello程序看看结果如何。
# gcc -o hello main.c -L. -lmyhello
# ./hello
Hello everyone!
#
我们删除静态库文件试试公用函数hello是否真的连接到目标文件 hello中了。
# rm libmyhello.a
rm: remove regular file `libmyhello.a'? y
# ./hello
Hello everyone!
#
程序照常运行,静态库中的公用函数已经连接到目标文件中了。
我们继续看看如何在Linux中创建动态库。我们还是从.o文件开始。
第5步:由.o文件创建动态库文件;
动态库文件名命名规范和静态库文件名命名规范类似,也是在动态库名增加前缀lib,但其文件扩展名为.so。例如:我们将创建的动态库名为myhello,则动态库文件名就是libmyhello.so。用gcc来创建动态库。
在系统提示符下键入以下命令得到动态库文件libmyhello.so。
# gcc -shared -fPCI -o libmyhello.so hello.o
#
我们照样使用ls命令看看动态库文件是否生成。
# ls
hello.c hello.h hello.o libmyhello.so main.c
#
第6步:在程序中使用动态库;
在程序中使用动态库和使用静态库完全一样,也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明动态库名进行编译。我们先运行gcc命令生成目标文件,再运行它看看结果。
# gcc -o hello main.c -L. -lmyhello
# ./hello
./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
#
哦!出错了。快看看错误提示,原来是找不到动态库文件libmyhello.so。程序在运行时,会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到,则载入动态库,否则将提示类似上述错误而终止程序运行。我们将文件 libmyhello.so复制到目录/usr/lib中,再试试。
# mv libmyhello.so /usr/lib
# ./hello
Hello everyone!
#
成功了。这也进一步说明了动态库在程序运行时是需要的。
我们回过头看看,发现使用静态库和使用动态库编译成目标程序使用的gcc命令完全一样,那当静态库和动态库同名时,gcc命令会使用哪个库文件呢?抱着对问题必究到底的心情,来试试看。
先删除 除.c和.h外的 所有文件,恢复成我们刚刚编辑完举例程序状态。
# rm -f hello hello.o /usr/lib/libmyhello.so
# ls
hello.c hello.h main.c
#
在来创建静态库文件libmyhello.a和动态库文件libmyhello.so。
# gcc -c hello.c
# ar cr libmyhello.a hello.o
# gcc -shared -fPCI -o libmyhello.so hello.o
# ls
hello.c hello.h hello.o libmyhello.a libmyhello.so main.c
#
通过上述最后一条ls命令,可以发现静态库文件libmyhello.a和动态库文件libmyhello.so都已经生成,并都在当前目录中。然后,我们运行gcc命令来使用函数库myhello生成目标文件hello,并运行程序 hello。
# gcc -o hello main.c -L. -lmyhello
# ./hello
./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
#
从程序hello运行的结果中很容易知道,当静态库和动态库同名时, gcc命令将优先使用动态库。
8. 什么叫静态库和动态库
两者区别:
一,静态库的使用需要:
1
包含一个对应的头文件告知编译器lib文件里面的具体内容
2
设置lib文件允许编译器去查找已经编译好的二进制代码
二,动态库的使用:
程序运行时需要加载动态库,对动态库有依赖性,需要手动加入动态库
三,依赖性:
静态链接表示静态性,在编译链接之后,
lib库中需要的资源已经在可执行程序中了,
也就是静态存在,没有依赖性了
动态,就是实时性,在运行的时候载入需要的资源,那么必须在运行的时候提供
需要的
动态库,有依赖性,
运行时候没有找到库就不能运行了
四,区别:
简单讲,静态库就是直接将需要的代码连接进可执行程序;动态库就是在需要调用其中的函数时,根据函数映射表找到该函数然后调入堆栈执行。
做成静态库可执行文件本身比较大,但不必附带动态库
做成动态库可执行文件本身比较小,但需要附带动态库
五:
首先纠正所谓“静态连接就是把需要的库函数放进你的exe之中”的说法。在真实世界中,有三个概念:use
static
libary,
static
linked
dll,
dynamic
linked
dll.
多数人混淆了static
libary
和
static
linked
dll的概念,当然他们有似是而非的“相似之处”,比如都用到.lib,下面具体说明。
使用静态库(use
static
libary)是把.lib和其他.obj一起build在目标文件中,目标文件可以是.exe,也可以是.dll或.oxc等。一般情况下,可以根本就没有“对应的”.dll
文件,如c
run
time(crt)库。一个例子就是,写一个main(){},build出来并不是只有几个字节,当然有人会说那还有exe文件头呢?是,即使加上文件头的尺寸,build出的执行文件仍然“莫名的大”。实际上那多出来的部分就是crt静态库。姑且可以把静态库.lib理解成外部程序的obj文件比较合理,它包含了函数的实现。
9. 如何让自己的程序动态引用debug和release的库
本文所描述的动态库是基于MFC的。IDE是VS2005. 默认情况下,如果一个动态库工程名叫A,动态库的名称将是A.lib A.dll A.def。不管工程是release下还是debug下。这就导致一个问题。如果我在另一个工程中使用这个动态库,这个工程在release下应该链接release下的相应库文件,这个工程在debug下应该链接debug下的相应库文件。于是乎,可能需要来回拷贝覆盖。甚是麻烦。为什么我们的动态库工程不能像OpenCV那样,debug就将默认生成的库名由默认的A.lib A.dll换成Ad.lib和Ad.dll呢?如果这能实现,我们在使用这些库的工程中的"项目"->"属性"->"链接器"->"输入"->"附加依赖库"里面分别设置不就OK了吗。 修改动态库名称的方法如下:(1) 打开动态库工程,设置DEBUG模式,然后选择"项目"->"属性"->"链接器"->"常规"->"输出文件",一般在文件名后附加 'd'即可。(2) 选择"项目"->"属性"->"链接器"->"高级"->"导入库",一般在文件名后附加 'd'即可。(3) 选择"项目"->"属性"->"链接器"->"输入"->"模块定义文件",一般在文件名后附加 'd'即可。注意:这里是需要一个模块定义文件,工程下默认只有 "工程名.def" 文件,需要将该文件复制一份,然后修改其中LIBRARY 后面引号中的内容加一个d。如; ListCtrlEx.def : Declares the mole parameters for the DLL.LIBRARY "ListCtrlEx" DESCRIPTION 'ListCtrlEx Windows Dynamic Link Library'EXPORTS ; Explicit exports can go here 修改后为:; ListCtrlEx.def : Declares the mole parameters for the DLL.LIBRARY "ListCtrlExd" ; Explicit exports can go here 如果不做这一步,在编译动态库时会出现如下警告 (4) release的个人认为无需改变。这样选择菜单"生成"->"批生成"生成debug和release版本的库。 ////////////////////////////////////////////////////////////////////////////////////////////////////////////// 到这里我们大概完成了任务的80%。接下来就像使用很多开源软件包一样,设置我们自己的工程。(1) 选择"项目"->"选项"->"项目和解决方案"->"C++目录",选择库文件,然后将刚刚生成的debug和release版本的库的路径填入。