MinGW gcc 生成动态链接库 dll 的一些问题汇总

网络上关于用 MinGW gcc 生成动态链接库的文章很多。介绍的方法也都略有不同。这次我在一个项目上刚好需要用到,所以就花了点时间将网上介绍的各种方法都实验了一遍。另外,还根据自己的理解试验了些网上没有提到的方法。这里,我就将这两天获得的成果总结一下。

首先说一下我的开发环境:

gcc version 4.9.2 (Rev1, Built by MSYS2 project)

Target: i686-w64-mingw32

Thread model: posix

--disable-sjlj-exceptions  --with-dwarf2

另外,为了试验生成的 dll 是否通用。测试代码时还用到了 Visual Stdio 2010。

在试验一种新的功能时,我一般会从最简单的代码开始。

//dlltest.c
int Double(int x)
{
    return x * 2;
}

下面的命令行将这个代码编译成 dll。

gcc dlltest.c -shared -o dlltest.dll -Wl,--out-implib,dlltest.lib

其中 -shared 告诉gcc dlltest.c 文件需要编译成动态链接库。-Wl 表示后面的内容是ld 的参数,需要传递给 ld。 --out-implib,dlltest.lib 表示让ld 生成一个名为 dlltest.lib 的导入库。

如果还需要 .def 文件,则上面的命令行可以写为:

gcc dlltest.c -shared -o dlltest.dll -Wl,--output-def,dlltest.def,--out-implib,dlltest.a

//main.c
#include <stdio.h>
int Double(int x);
int main(void)
{
        printf("Hello :%d\n", Double(333));
        return 0;
}

gcc main.c dlltest.lib -o main.exe

运行结果为:

Hello :666

说明生成的dlltest.dll是正确的。另外,也可以用dependecy walker 查看相互调用的关系。

实际上,如果我们的dll文件只是被MinGW gcc使用。都不需要生成 dlltest.lib。直接在编译的时候将 dlltest.dll 加进去就行了。

gcc main.c dlltest.dll -o main.exe

如果在程序中动态加载dll。那么代码可以这么写:

//m2.c
define UNICODE 1

#include <windows.h>
#include <stdio.h>

typedef int (*INT_FUNC)(int);
int main(void)
{
	INT_FUNC db;
	HINSTANCE hInstLibrary = LoadLibrary(L"dlltest.dll");
	printf("LoadLibrary\n");
	db = (INT_FUNC)GetProcAddress(hInstLibrary, "Double");

	printf("Hello :%d\n", db(333));
	FreeLibrary(hInstLibrary); 

	return 0;
}

编译的时候更不需要dlltest.lib 了,甚至都不需要 dlltest,dll。

gcc m2.c -o m2.exe

运行的结果也是正确的。

那么这个dll 可以被其他c编译器使用吗?利用VC 2010来测试表明,可以生成exe文件。如果是生成Debug模式的exe文件,执行是正常的。但是改为release模式后,每次运行都会报错。

用VS2010 的调试功能,看了看反汇编的结果。看似都是正常的。

int _tmain(int argc, _TCHAR* argv[])
{
	int a;
	a = Double(333);
01021000  push        14Dh
01021005  call        _Double (1021024h)
	printf("Hello :%d\n", a);
0102100A  push        eax
0102100B  push        offset string "Hello :%d\n" (10220F4h)
01021010  call        dword ptr [__imp__printf (10220A0h)]
01021016  add         esp,0Ch
	getchar();
01021019  call        dword ptr [__imp__getchar (102209Ch)]
	return 0;
0102101F  xor         eax,eax
}

单步跟进_Double 函数后是这样的:

_Double:
01021024  jmp         dword ptr ds:[1020000h]
0102102A  nop
0102102B  nop  

Jmp 语句后:

00905A4D  ???
00905A4E  ???
00905A4F  ???
00905A50  ???
00905A51  ???
00905A52  ???
00905A53  ???  

可是在Debug 模式下:

_Double:
011B144C  jmp         dword ptr [__imp__Double (11B8340h)]
011B1452  nop
011B1453  nop
011B1454  int         3
011B1455  int         3  

Jmp 语句后:

6C101560  push        ebp
6C101561  mov         ebp,esp
6C101563  mov         eax,dword ptr [ebp+8]
6C101566  add         eax,eax
6C101568  pop         ebp
6C101569  ret  

而从下图可以看出,dlltest.dll 被加载到 6C100000 是正确的。

没有想明白为什么会这样,看来还需要努力,到目前为止只成功了一小步。不过,如果是动态调用dll,却没有问题。

#include <windows.h>

typedef int (*INT_FUNC)(int);
int _tmain(int argc, _TCHAR* argv[])
{
	INT_FUNC db;
	HINSTANCE hInstLibrary = LoadLibrary(L"dlltest.dll");
	printf("LoadLibrary ");
	db = (INT_FUNC)GetProcAddress(hInstLibrary, "Double");

	printf("Hello :%d\n", db(333));
	FreeLibrary(hInstLibrary);
	getchar();
	return 0;
}

这个代码用 VC2010 编译执行一点问题都没有。很是奇怪。在网上查找了一番,发现可能是 MinGW gcc 生成的 lib 文件与 VC 生成的lib 文件有些细微的差别,导致在VC环境下,Debug模式下工作正常,而Release 模式工作却不正常。为了验证这个结论,又找了些资料学会了如何从dll文件生成VC下可用的lib文件。

下面的方法参考了这篇博客:

http://blog.sina.com.cn/s/blog_4f183d960100gqfj.html

生成VC下可用的lib文件需要有 def 文件,前面已经说过 -Wl,--output-def,dlltest.def  就可以生成对应的def 文件。

有了def文件之后,利用VS2010 提供的lib.exe可以生成对应的lib文件。

lib /machine:ix86 /def:dlltest.def

将生成的dlltest.lib 文件拷到VC项目中。编译,运行,一切正常。

我们知道 WinAPI 函数是符合 Pascal 函数调用约定的,也就是所谓的 stdcall。而刚才生成的dll 中的函数是使用的 C语言函数调用约定(__cdecl )。如果将其改为Pascal 函数调用约定需要修改程序代码。

//dlltest.c
int _stdcall Double(int x)
{
    return x * 2;
}

//main.c
#include <stdio.h>
int _stdcall Double(int x);
int main(void)
{
        printf("Hello :%d\n", Double(333));
        return 0;
}

编译命令是不变的。但是需要注意的是,这时生成的dll 文件中的函数名是有变化的。可以参看下图。原来是Double 现在变成了 [email protected],变成了这种类似 C++ 函数的名字了。但是这样并不影响使用。

网上关于生成和使用dll 的文章都会写到,生成dll 是函数声明需添加 __declspec(dllexport),而使用dll时函数声明要使用__declspec(dllimport)。大家都看到了,我前面的代码中这两个都没有用到。那么这两个声明有什么用呢。下面就做个测试。

首先在生成dll 的代码中增加:

//dlltest.c
int __declspec(dllexport) _stdcall Double(int x);

int _stdcall Double(int x)
{
    return x * 2;
}

编译命令如下:

gcc dlltest.c -shared -o dlltest.dll -Wl,--output-def,dlltest.def,--out-implib,dlltest.a

M.c 文件不变:

//m.c
#include <stdio.h>

int _stdcall Double(int x);

int main(void)
{
        printf("Hello :%d\n", Double(333));
        return 0;
}

编译命令如下:

gcc m.c dlltest.a -o m2.exe

编译没有问题,执行也没有问题。

修改一下m.c 。

//m.c
#include <stdio.h>

int __declspec(dllimport) _stdcall Double(int x);

int main(void)
{
        printf("Hello :%d\n", Double(333));
        return 0;
}

编译命令如下:

Gcc m.c dlltest.a -o m2.exe

编译没有问题,执行也没有问题。

再修改一下main.c 。

//main.c
#include <stdio.h>

int __declspec(dllexport) _stdcall Double(int x);

int main(void)
{
        printf("Hello :%d\n", Double(333));
        return 0;
}

编译命令如下:

Gcc main.c dlltest.a -o m2.exe

编译没有问题,执行也没有问题。 这个实验说明__declspec(dllexport)对于函数声明其实是没什么作用的。我也比较过生成的代码的反汇编结果,也是没区别的。并不像有些人所说增加了__declspec(dllexport)之后生成的代码能够更精炼。当然,这也可能是现在编译器的优化能力越来越强的结果。早期编译器跟不上,可能还是有区别的。

但是__declspec(dllexport)对于输出变量是有影响的。看下面的测试代码:

//dlltest.c
int Double(int x);
int xxx = 123;
int Double(int x)
{
    return x * 2;
}

//m.c
#include <stdio.h>

int Double(int x);
extern int xxx;
int main(void)
{
        printf("Hello :%d\n", Double(333));
        printf("%d", xxx);
        return 0;
}

编译:

gcc dlltest.c -shared -o dlltest.dll -Wl,--output-def,dlltest.def,--out-implib,dlltest.a

lib /machine:ix86 /def:dlltest.def

gcc m.c dlltest.a -o mm.exe

这样是可以编译执行的,说明dlltest.a 中包含了足够的信息。

但是第三句改为:

gcc m.c dlltest.lib -o mm.exe

则会有如下的错误,这也说明dlltest.a 和dlltest.lib 确实有些很小的差异。

undefined reference to `xxx‘

collect2.exe: error: ld returned 1 exit status

VS2010 编译也是类似的错误,无法找到符号 xxx的定义。即使是main.c中增加了如下的声明:extern int __declspec(dllimport) xxx;

结果也是类似的:error LNK2001: 无法解析的外部符号 __imp__xxx

说明dlltest.lib 中就没有 xxx 的相关信息,不可能访问到dlltest.dll 中的xxx。

如果将dll的全局变量声明中增加 __declspec(dllexport) ,结果就不一样了。

//dlltest.c
int Double(int x);
int  __declspec(dllexport)  xxx = 123;
int Double(int x)
{
    return x * 2;
}

//m.c
#include <stdio.h>

int Double(int x);
extern int xxx;
int main(void)
{
        printf("Hello :%d\n", Double(333));
        printf("%d", xxx);
        return 0;
}

gcc dlltest.c -shared -o dlltest.dll -Wl,--output-def,dlltest.def,--out-implib,dlltest.a

lib /machine:ix86 /def:dlltest.def

gcc m.c dlltest.a -o mm.exe

编译成功,

gcc m.c dlltest.lib -o mm.exe

还是失败的。

在VS2010中编译 m.c,仍然是失败的。报的错误是:

error LNK2001: 无法解析的外部符号 _xxx

m.c 做一些修改。增加 __declspec(dllimport)

//m.c
#include <stdio.h>

int Double(int x);
int __declspec(dllimport) xxx;
int main(void)
{
        printf("Hello :%d\n", Double(333));
        printf("%d", xxx);
        return 0;
}

VS2010 中编译就可以通过。另外,再多说一句,我试验的结果表明,__declspec(dllimport) 与__declspec(dllexport) 对于编译来说似乎没有任何区别,字面上的区别完全是给程序员自己看的。

至此,MinGW gcc 生成 dll 的常见问题就都解决了。

时间: 2024-10-06 06:26:54

MinGW gcc 生成动态链接库 dll 的一些问题汇总的相关文章

dll = MinGW gcc 生成动态链接库 dll 的一些问题汇总

MinGW gcc 生成动态链接库 dll 的一些问题汇总 https://blog.csdn.net/liyuanbhu/article/details/42612365 网络上关于用 MinGW gcc 生成动态链接库的文章很多.介绍的方法也都略有不同.这次我在一个项目上刚好需要用到,所以就花了点时间将网上介绍的各种方法都实验了一遍.另外,还根据自己的理解试验了些网上没有提到的方法.这里,我就将这两天获得的成果总结一下. 首先说一下我的开发环境: gcc version 4.9.2 (Rev

MinGW gcc 生成动态链接库 dll 的一些问题汇总 (补充)

我曾经写过一个小短文,介绍MinGW gcc 生成动态链接库 dll 的一些问题.当时写的并不全面.最近又遇到写新的问题.这里记录一下,做个补充. 通常情况下,dll 中的函数如果采用 _stdcall ,则生成的dll中函数名会被修饰. 比如有如下的函数: //dll.c int  _stdcall add(int a, int b) { return a + b; } 最终 dll 文件中的函数名是 [email protected] 但是有时我们希望函数名不要添加这种修饰,就像 windo

gcc 生成动态链接库

http://blog.csdn.net/ngvjai/article/details/8520840 Linux下文件的类型是不依赖于其后缀名的,但一般来讲: .o,是目标文件,相当于windows中的.obj文件 .so 为共享库,是shared object,用于动态连接的,和dll差不多 .a为静态库,是好多个.o合在一起,用于静态连接 .la为libtool自动生成的一些共享库,vi编辑查看,主要记录了一些配置信息.可以用如下命令查看*.la文件的格式   $file *.la    

关于linux下GCC生成共享库(动态链接库)的探究

下面列出了我在对共享库(动态链接库)编写以及使用时遇到的几个简单问题进行探究和解答: 参考文档:http://www.cnblogs.com/likwo/archive/2012/05/09/2492225.html 1.静态库.动态链接库.共享库有什么区别? 静态库(windows下为.lib,linux下为.a)是在程序编写前就编译到目标程序中了,而动态链接库(windows下为.dll)可以在程序执行的任何时候被动态加载.共享库(linux下为.so)是在程序启动的时候加载到程序中. 1)

MinGW(GCC)编译DLL文件

这两天用CB(Code::Blocks)写个小程序,要编译出DLL供VB(6)使用.CB使用mingw-gcc作为编译器,在库文件的产出上跟VC.VS之类的IDE略有不同. 由于C语言的基础知识不是太好,尤其对编译环节更是知之甚少.结果,试了几次,导出的DLL中的函数总是无法被调用. 用VB加载时总是提示"DLL调用约定错误",百度之了解到VB只能调用适配__stdcall约定(这也是其他语言也能调用C的默认方式)的函数. 于是在源文件中的函数前加上__stdcall,导出后又提示&q

利用GCC编译器生成动态链接库和静态链接库

转载请标明:http://www.cnblogs.com/winifred-tang94/ 1.编译过程 gcc –fPIC –c xxx.c 其中-fPIC是通知gcc编译器产生位置独立的目标代码.链接的时候不通过拷贝来进行. 2.链接过程 gcc –shared –o libxxx.so xxx.o 经过编译链接就可以生成动态链接库,其扩展名为.so Eg. 还可以gcc –fPIC –shared -o libhello.so hello.c 举个例子: //Hello.h //hello

MinGW 使用和创建 DLL 应注意的问题

MinGW 是 GCC 的 Windows 版本,稳定版已经到了 4.5.2,功能和性能上很好,感觉不比 Microsoft 自家的 VC 差啊.但是 MinGW 下使用和创建 DLL 倒是要特别注意,问题主要集中在 g++ 编译器(C++ 的 GNU 版本编译器)对于 DLL 的函数输入以及输出的名称修饰.调用协议上和 VC 编译器是有很大区别的. 1.MinGW 如何使用一个标准的 DLL.这里标准 DLL 指的是采用 __stdcall 调用协议.并且导出函数名称干干净净,没有函数名尾部的

gcc编译动态链接库

以下是windows环境下用gcc编译动态链接库的尝试过程. 环境准备 编译使用的MinGW,64位的官网可以找到下载地址. 项目建立及代码编写 在任意地方新建一个目录,保存这个项目,然后新建一个c源程序文件main.c,输入程序. 编译 用控制台输入以下命令编译动态链接库 gcc -shared -Wall -o main.dll main.c

动态链接库dll,导入库lib,静态链接库lib

目前以lib后缀的库有两种,一种为静态链接库(Static Libary,以下简称“静态库”),另一种为动态连接库(DLL,以下简称“动态库”)的导入库(Import Libary,以下简称“导入库”).  静态库是一个或者多个obj文件的打包,所以有人干脆把从obj文件生成lib的过程称为Archive,即合并到一起.比如你链接一个静态库,如果其中有错,它会准确的找到是哪个obj有错,即静态lib只是壳子.  动态库一般会有对应的导入库,方便程序静态载入动态链接库,否则你可能就需要自己Load