我以前写过一个小短文,介绍MinGW gcc 生成动态链接库 dll 的一些问题.当时写的并不全面.近期又遇到写新的问题.这里记录一下,做个补充. 通常情况下,dll 中的函数假设採用 _stdcall ,则生成的dll中函数名会被修饰. 比方有例如以下的函数: //dll.c int  _stdcall add(int a, int b) {     return a + b; } 终于 dll 文件里的函数名是 add@8 可是有时我们希望函数名不要加入这样的修饰,就像 windows ap

用于隐式链接选项, 这样设置后在exe调用dll的函数才会加载dll,调用DLL_PROCESS_ATTACH.否则隐式链接直接会在exe启动时加载dll

dll不仅可以导入导出函数,还可以导入导出类.这篇文章就来介绍如何将类导入dll中并导出. 首先我们建立一个名为dll.cpp的文件(又是这种破名字),里面写上: #include <iostream> using namespace std; #define EXPORT __declspec(dllexport) extern "C"{ class EXPORT CLASS; //要导入的类 } class CLASS{ //类的主体 public: int a,b;

将MinGW编译的openssl dll导出def和lib供MSVC使用 前面我们用mingw把openssl 编译成了动态库,得到下面2个dll文件: libeay32.dll ssleay32.dll 然后用下面的脚本生成Windows MSVC需要的模块定义文件(.def, .lib和.exp), 然后就可以在VC中使用了. 前提系统要安装VS. 系统要求: Windows7+VS Studio (2008 and later)+MSYS 1) 根据32位dll生成模块定义文件的pytho

原文地址:mingw qt作者:孙1东 不使用Qt SDK,使用mingw编译qt源代码所遇问题及解决方法: configure -fast -release -no-exceptions -no-rtti -no-stl -no-qt3support -no-opengl -no-multimedia -no-webkit -no-script -no-scripttools -nomake tools -nomake examples -nomake demos -nomake docs -

最近碰到了一个问题,要引入一个第三方的SDK,但是SDK中使用的一些dll和我原本程序里面有些dll是同名的,而且本程序的dll和sdk的dll名称都不能修改. 解决这个问题,首先想到的就是多进程,这就用到了我们之前开发的一个专门用来托管dll的进程.先是将SDK打包到另外一个单独的目录(因为与本程序中的dll名称冲突),随后写了一个包装SDK的dll,把这个dll给了托管进程. 这样既使用了SDK的功能,又把第三方的程序隔离开了,看似不错的解决方案. 但是遇到了另外一个问题,我的托管进程也是在

Posted February 26th, 2009 by earnie dll faq msvc TODO: Reformat to new wiki syntax. !!! [Minimalist GNU for Windows | http://www.mingw.org] !! MSVC and MinGW DLLs Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will comp

DLL延时加载技术与资源释放 0x00 前言 诸如调用非Windows的第三方库,我们或许会使用到dll文件,而这个时候原本程序运行需要相应的dll文件才能加载启动.通过DLL延时加载技术,使用延时加载的方式编译链接可执行的文件,可以先运行程序,再在依赖的DLL正式被调用时加载DLL.通常可通过资源文件写入dll,在释放完资源后,正式调用DLL时加载执行,避免丢失缺少DLL文件,从而单exe落地文件,避免麻烦. 0x01 介绍 在使用Visual Studio的场景下,如果使用DLL延时加载,只

MSVC在编译C/C++程序的时候,默认采用__cdecl调用约定来编译.__stdcall是Win32 API函数的默认调用规约. Calling Convention Internal* MSVC DLL (w/ DEF) MSVC DLL (dllexport) DMC DLL MinGW DLL BCC DLL __stdcall _Function@n Function _Function@n _Function@n Function@n Function __cdecl _Funct

xmake 是一个基于 Lua 的轻量级跨平台构建工具,使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上. 在 2.5.2 版本中,我们增加了一个重量级的新特性:自动拉取远程交叉编译工具链. 这是用来干什么的呢,做过交叉编译以及有 C/C++ 项目移植经验的同学应该知道,折腾各种交叉编译工具链,移植编译项目是非常麻烦的一件事,需要自己下载对应工具链

MinGW 编译出来的程序总是使用 VC6 的 msvcrt.dll ,VC8,9,10有很多新的API(仅限于c runtime),想使用怎么办? 比如:boost 对 MinGW 最低要求就是 msvcrt 7.0   1.MinGW 系统默认情况 MinGW 根据宏 MSVCRT_VERSION 来选择 msvcr 版本,如果用户未指定则默认使用 VC7 的 API(bug, MinGW 默认链接的是 msvcrt.dll, 虽然与 msvcr70.dll 差别不是太大)   MinGW

MinGW:c -> o           gcc -c a.cc -> exe         gcc a.c libs.o -o a.exe (从主程序a.c,附加libs,生成a.exe)o -> exe         gcc a.o b.o ... -o main.exec -> dll,def,a   gcc a.c -shared -o a.dll -Wl,--output-def,a.def,--out-implib,liba.aa -> dll      

用Qt写点东西,我一般是下载官方的MinGW编译工具包,它有个不好的地方,经常还会多一些除了Qt库以外的其它的依赖动态链接库,比如:libgcc_s_dw2-1.dll,libstdc++-6.dll这样的鬼东西,之前用CodeBlock的时候发现没有这样的现像,就感觉很奇怪,于是仔细查找了一此资料,原来这些东西可以通过设置编译器选项把它们去掉的,其实就是改成静态链接依赖库中的代码. 我这里是直接修改Qt编译后的配置,找到QTDIR/mkspec/win32-g++ /qmake.conf,QM

关于gcc编译dll的我就不说了,网上举例一大堆,下面以g++为例. 假设有一个test.cpp文件如下: extern "C" { __declspec(dllexport) double add(double x,double y); } double add(double x,double y){ return x+y; } 在MinGW中使用g++编译: g++ -shared -Wl,--kill-at,--output-def,test.def -o test.dll te

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

以前很少调用MinGW的运行时库,现在用到一个项目,用到了glib和gettext等. 遇到了一个问题,折腾了一个下午. gettext的运行时库之一是intl,MinGW只提供了.dll.a,于是参考了网上其它的介绍,像其它.lib一样调用 pragma comment(lib, "libintl.dll.a") 结果就出现了 无法定位程序输入点 GdiplusStartup于动态链接库libintl-8.dll上. 我坚信libintl没有用到GDI+,Depends查看dll后证

1,下面的命令行将这个代码编译成 dll. gcc mydll.c -shared -o mydll.dll -Wl,--out-implib,mydll.lib 其中 -shared 告诉gcc dlltest.c 文件需要编译成动态链接库.-Wl 表示后面的内容是ld 的参数,需要传递给 ld. --out-implib,dlltest.lib 表示让ld 生成一个名为 dlltest.lib 的导入库. 如果还需要 .def 文件,则上面的命令行可以写为: gcc mydll.c -sha

一份粗糙的研究记录,有待补完和整理. MinGW:c -> o           gcc -c a.cc -> exe         gcc a.c libs.o -o a.exe (从主程序a.c,附加libs,生成a.exe)o -> exe         gcc a.o b.o ... -o main.exec -> dll,def,a   gcc a.c -shared -o a.dll -Wl,--output-def,a.def,--out-implib,liba

使用C#调用mingw的so,报了c# 无法加载DLL“###.so”,: 找不到指定的程序. (异常来自 HRESULT:0x8007007E)开始以为是dll路径问题,使用全路径确认正确后仍然无法解决.然后通过加载其他so文件,发现报的错误是找不到函数符号,而不是找不到指定程序.所以认为是这个so的特定问题,又检查了so文件的位数,和C#程序的位数,都是32位.经过分析,如果能确定dll位置是正确的,则调用的DLL文件使用到其他DLL文件也需要能够正确引用.所以将so文件引用的libtiff

dll隐式链接延迟加载 程序隐式链接dll后,启动程序将自动加载dll,查找路径依次是: 1:当前文件路径: 2:使用SetDLLDirectory设置的路径: 3:系统路径,system32文件夹,可使用GetSystemDirectory函数查看: 4:windows路径,可使用GetWindowsDirectory函数查看: 5:设置的系统路径: 用Depends查看exe依赖项,非延迟加载的exe如下图所示: 非延迟加载的exe打开后会按照上诉路径去查找dll,找不到dll会报错.导致打