IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib)

这篇具有很好参考价值的文章主要介绍了IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

概述

本文介绍了 QtCreator + mingW 集成开发环境下的动态库生成和使用方法,重点分析了mingw下动态库项目编译后生成的*.a文件的作用到底是什么。本文还对比分析了mingw下动态库的部署和使用与MSVC下动态库生成和使用方式上的不同。
使用MingW编译器时,没有生成.lib引导文件,那么mingW是如何完成动态库链接过程的呢?而且经验告诉我们,mingw下,可执行程序使用dll时,是可以直接指向dll文件进行编译链接过程的,它是怎么做到的呢?

关于VS集成开发环境下的DLL生成和部署使用,可参考《IDE/在VS下DLL动态库的部署和加载问题分析》,以更好对比分析。

MinGW 提供了一个开发环境,可以方便地在 Windows 平台上进行 C、C++ 和其他编程语言的开发。开发人员可以使用 MinGW 提供的工具和库来编写 Windows 应用程序,而不需要依赖于 Microsoft Visual Studio 或其他商业开发工具。MinGW 是基于 GNU 工具集的一个分支,它允许开发人员在 Windows 环境中使用类似于 Linux 下的开发工具,如 GCC 编译器、GNU Make 等,以及一些常用的库文件,如 C/C++ 运行时库、Windows API 的头文件等。

问题的产生

Demo 代码 的总体目录分布,E:\TestDll,下设:bin、bin_d、DllOfMingw、ExeOfMingw 目录,DllOfMingw.pro 位于DllOfMingw目录;ExeOfMingw.pro 位于 ExeOfMingw 目录。特殊测试步骤上,还设 E:\TestDll\lib 目录。

基于mingw的DLL动态库

在 Qt Creator 文件菜单下,选择新建文件或项目,在弹出的选项卡中,选择 Library - C++ Library,新建名为 DllOfMingw 的工程。
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
Qt modules 选择 Qt 无关,Kits 选择 Mingw 64…

//DllOfMingw.pro 
CONFIG -= qt

TEMPLATE = lib
DEFINES += DLLOFMINGW_LIBRARY

CONFIG += c++11

Debug:DESTDIR = $$PWD/../bin_d
Debug: TARGET = dllofmingw_d

Release: DESTDIR = $$PWD/../bin
Release: TARGET = dllofmingw

SOURCES += \
    dllofmingw.cpp

HEADERS += \
    dllofmingw.h \
    dllofmingw_global.h

DEFINES += QT_DEPRECATED_WARNINGS
//dllofmingw_global.h
#ifndef DLLOFMINGW_GLOBAL_H
#define DLLOFMINGW_GLOBAL_H

#if defined(_MSC_VER) || defined(WIN64) || defined(_WIN64) || defined(__WIN64__) || defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__NT__)
#  define Q_DECL_EXPORT __declspec(dllexport)
#  define Q_DECL_IMPORT __declspec(dllimport)
#else
#  define Q_DECL_EXPORT     __attribute__((visibility("default")))
#  define Q_DECL_IMPORT     __attribute__((visibility("default")))
#endif

#if defined(DLLOFMINGW_LIBRARY)
#  define DLLOFMINGW_EXPORT Q_DECL_EXPORT
#else
#  define DLLOFMINGW_EXPORT Q_DECL_IMPORT
#endif

#endif // DLLOFMINGW_GLOBAL_H
//dllofmingw.h
#ifndef DLLOFMINGW_H
#define DLLOFMINGW_H
#include <string>
#include "dllofmingw_global.h"

class DLLOFMINGW_EXPORT DllOfMingw
{
public:
    DllOfMingw();
public:
    std::string InvokeTest();
};
#endif // DLLOFMINGW_H
//dllofmingw.cpp
#include "dllofmingw.h"

DllOfMingw::DllOfMingw() { }

std::stringDllOfMingw::InvokeTest()
{ return "Dll Interface was invoked!"; }

以Debug模式编译上述项目,在E:\TestDll\bin_d目录下生成两个文件,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
它们是干什么的,尤其是 libdllofmingw_d.a 到底是干什么的,容后再叙。

基于mingw的EXE可执行程序

在 Qt Creator 文件菜单下,选择新建文件或项目,在弹出的选项卡中,选择 Application,新建名为 ExeOfMingw 的Qt控制台工程。选择与DLL项目相同的Kits设置。项目创建与DLL一致,均为 E:\TestDll 目录。

//ExeOfMingw.pro
QT -= gui

CONFIG += c++11 console
CONFIG -= app_bundle

DEFINES += QT_DEPRECATED_WARNINGS

SOURCES += \
        main.cpp

# you'd better build a public include
INCLUDEPATH += $$PWD/../DllOfMingw

win32 {
    Debug:LIBS  +=   -L$$PWD/../bin_d \
                     -ldllofmingw_d

    Release:LIBS  += -L$$PWD/../bin \
                      -ldllofmingw
}

# .exe's dir same as .dll file
Debug:DESTDIR = $$PWD/../bin_d
Release: DESTDIR = $$PWD/../bin
//mian.cpp
#include <QCoreApplication>
#include <QDebug>
#include "dllofmingw.h"

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    DllOfMingw aDll;
    qDebug() << QString::fromLocal8Bit(aDll.InvokeTest().c_str());

    return a.exec();
}

Makefile文件中使用Qt库的*.a文件

在上述测试代码下,DLL和EXE均可正常编译和执行。运行可输出 “Dll Interface was invoked!”…

之前在整理其他集成开发环境相关问题的时候就发现过,在Makefile文件中,LIBS中对Qt库的引用使用的是*.a文件,当时只作了记录并未细究。以上述正常编译和运行的代码为例子,打开ExeOfMingw 项目编译目录下的 Makefile.Debug 文件,

LIBS = -LE:\TestDll\bin_d -ldllofmingw_d D:\Qt\Qt5.12.8\5.12.8\mingw73_64\lib\libQt5Cored.a  

此时的相关的编译输出,截图如下,可以与makefile相互匹配上,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
可惜的是,我们无法通过红色框标记的内容,来判断出 ExeOfMingw 在编译阶段,到底使用了 dllofmingw_d.dll 和 libdllofmingw_d.a 的哪一个。不过,看到 ExeOfMingw 在LIBS中引用的是libQt5Cored.a 文件,我们大概率先猜测,“-LE:\TestDll\bin_d -ldllofmingw_d” 会指向 $$PWD/…/bin_d/libdllofmingw_d.a 文件,但事实如此吗?

mingw下的*.a 文件 和 *.dll 到底谁起作用

单纯地结合VS下动态库部署和执行的相关理论常识,DLL它也不应该与编译有关才对!但是以往的经验早就告诉了我们,在mingw编译套件下,dll文件似乎是在编译过程中起到作用的。为此,我们将在上述正常编译和运行的程序部署的基础上,逐步展开测试。注意,为了保证测试的可靠性,我每次重新编译前,均是手动删除上次编译生成的过程文件。

Test-1
我们重点关注 libdllofmingw_d.a 这个文件,并猜测它可能与 MSVC编译器下的动态库引导文件起到了相同的作用。为此,我们删除 E:\TestDll\bin_d\libdllofmingw_d.a 文件,重新执行 ExeOfMingw 编译,并无编译异常发生,运行也无误。
Test-2
然后我们将 libdllofmingw_d.a 恢复回来,将 dllofmingw_d.dll 删除,再次重新执行 ExeOfMingw 编译,也不存在编译异常。dll是运行时加载使用的,没有它,程序肯定是无法正常运行的。
Test-3
我们在 《IDE/集成开发环境 Qt Creator+MSVC编译器+CDB调试器》文中,已经测试过,在使用MSVC编译器的情况下,pro工程文件中的LIBS必须配置动态库引导文件lib的路径和名称,否则无法通过编译。前文中的测试,我们每次只是删除了 dllofmingw_d.dll 或 libdllofmingw_d.a 中的一个,如果两个一起删除呢?
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
呢,编译报错了,找不到指定的 dllofmingw_d 库了。而且此处的含义应该是:即没有找到 dllofmingw_d.dll ,也没有找到 libdllofmingw_d.a 文件。因为,但凡他俩存在一个,都没有出现编译错误。
再来一轮回归测试,
只将 dllofmingw_d.dll 添加回到 E:\TestDll\bin_d,编译 ExeOfMingw 无误,运行无误。
只将 libdllofmingw_d.a 添加回到 E:\TestDll\bin_d,编译 ExeOfMingw 无误,但程序无法正常运行。
Test-4
来点狠的,使用migw编译器时,我若不进行 LIBS配置,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程

临时结论,
引用 mingw编译的DLL时,也必须要配置 LIBS 路径和文件,但是对于编译过程,只要存在 dllofmingw_d.dll 或 libdllofmingw_d.a 中的其中任意一个,即可通过编译过程。因此可以猜测?mingw编译动态库项目时生成的 *.lib文件 和 *.a 文件,都可以在编译环节支持链接到调用它的可执行程序中。

验证 *.a文件对编译过程的支持,
进一步的,我们将 *.a 脱离 bin文件夹,放到单独的E:\TestDll\lib文件夹下,dllofmingw_d.dll依然放在E:\TestDll\bin_d下,相应的修改 ExeOfMingw.pro 文件中的 LIBS 配置,

win32 {
    Debug:LIBS  +=   -L$$PWD/../lib \
                     -ldllofmingw_d

    Release:LIBS  += -L$$PWD/../lib \
                      -ldllofmingw
}

经过测试,可以通过编译过程,运行也没有任何异常。

最后的几个结论,

  • mingw下的动态库引用,也是必须要进行LIBS配置的。
  • mingw下编译动态库项目时生成的 lib*.a文件,可以用以编译链接过程。
  • 且qmke构建的项目中,对Qt框架库的引用,LIBS配置的就是 *.a类型的文件。
  • 如果没有 *.a文件,只有mingw下生成的.dll文件,也是能支持编译链接过程的。

如此看来,针对动态库项目,把mingw下的*.a文件类比为MSVC下的*.lib引导文件,并没有什么大问题,它们的命名方式和功能都基本一致。差别较大的地方在于,mingw下的.dll类型的文件,自身也可以参与编译链接过程,而msvc下生成的.dll文件并没有此功能。

小插曲

在某个测试阶段,我遇到了如下运行异常。编译没有问题,但是程序总是无法启动,连main函数都进不去。
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
尝试,重新启动QtCreator 并未生效。“qtcreator_process_stub.exe” 是 Qt Creator 中用于与正在调试的应用程序进行交互的帮助进程。它允许 Qt Creator 与应用程序进行通信,设置断点,检查变量并控制调试过程。如上错误消息,“qtcreator_process_stub.exe” 进程无法启动,但返回 “操作成功完成”,意味着进程的执行本身并没有发生错误,操作系统返回的进程退出代码是 “0”,代表进程正常退出。

我将,dllofmingw_d.dll 和 ExeOfMingw.exe 拷贝到Qt对应的bin库下执行,没有问题。我关机重启了PC,依然无济于事。于是,我将关于动态库的引用全部注释掉,也无济于事。我随便新建一个新的控制台应用程序,测试我的IDE环境有没有问题? 结果悲催了,不能用了竟然。难道,我的IDE被Qt公司使绊子啦?
使用 Everything 搜索 qtcreator_process_stub 找到它,D:\Qt\Qt5.9.3\Tools\QtCreator\bin,并使用命令窗口执行它,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
结合此情此景,我还能想到的可能是,杀毒软件,打开,果然,从隔离区将上述文件恢复后,相关问题不攻自破。
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程

mingw 生成的 *.a文件到底是什么

在VS & MSVC下当我们使用 动态库隐式加载方式时,必须要有 *.lib的动态引导文件,才可以正常编译。在mingw下没有 *.lib文件生成, *.a 文件看上去倒是有点类似 MSVC下的 *.lib,但此时我还不确定 *.a文件到底是啥 ?有的资料中显示, *.a 文件是静态库文件,但我觉得这就跟有人胡说MSVC下的 *.lib文件是静态库文件一样。

为进一步说明,mingw下的 *.a 文件不是静态库文件,我们新建一个mingw下的静态库项目,将其实现成DLL一致,并对比它们。

在 Qt Creator 文件菜单下,选择新建文件或项目,在弹出的选项卡中,选择 Library - C++ Library,项目名称 SllOfMingw,创建路径为E:\TestDll,与DLL项目一致。选择项目类型为 Statically Linked Library 静态链接库。Qt module 还是none,与Qt无关,Kits也还选择mingw 64… 将 SllOfMingw 类与 DllOfMingw 类 做一致的实现…
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
观察静态库项目,发现,其没有了DLL项目下的 dllofmingw_global.h 这样的导出宏定义;pro文件相比DLL,其中多出来一个 CONFIG += staticlib 配置。为了具有更好的可比性,我们将SLL和DLL实现为一样的接口和属性。

//SllOfMingw.pro
CONFIG -= qt
CONFIG += c++11

TEMPLATE = lib
CONFIG += staticlib

DEFINES += QT_DEPRECATED_WARNINGS

Debug:DESTDIR = $$PWD/../bin_d
Debug: TARGET = sllofmingw_d

Release: DESTDIR = $$PWD/../bin
Release: TARGET = sllofmingw

SOURCES += \
    sllofmingw.cpp
HEADERS += \
    sllofmingw.h
//sllofmingw.h
#ifndef SLLOFMINGW_H
#define SLLOFMINGW_H

#include <string>

class SllOfMingw
{
public:
    SllOfMingw();
public:
    std::string InvokeTest();
};

#endif // SLLOFMINGW_H
//sllofmingw.cpp
#include "sllofmingw.h"

SllOfMingw::SllOfMingw() { }

std::string SllOfMingw::InvokeTest() {
    return "Sll Interface was invoked!"; }

编译完成后可知,该静态库项目仅仅生成了名为 libsllofmingw_d.a 的静态库文件,如下红框标记。
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
另外,
我们也注意到,虽然都是.a静态库文件类型的后缀,但是 libsllofmingw_d.a 真静态库文件比 libdllofmingw_d.a 这假静态库文件要大一个数量级。因此可断定,libdllofmingw_d.a 不是真正的静态库文件,这与MSVC下编译生成的*.lib文件不是真正的静态库文件如出一辙。与MSVC下的.lib引导文件一样,mingw动态库项目生成的.a类型的文件,也具有参与编译链接过程的能力,顾,完全也可以称此时的.a文件为mingw下的动态库引导文件。

为啥mingw的dll可用以编译链接过程

先给自己广普下编译器的链接过程,
编译器的连接过程是将多个编译后的目标文件(通常是 .obj 文件)和库文件(静态库或动态库)合并成最终的可执行文件或共享库的过程。连接器Linker的连接过程通常分为以下几个步骤:
符号解析(Symbol Resolution):连接器首先需要解析目标文件中的符号引用。符号引用是指在一个目标文件中引用了另一个目标文件或库文件中定义的函数、变量等符号。
地址重定位(Address Relocation):解析完符号引用后,连接器需要对引用进行地址重定位。这是因为目标文件中的符号地址是相对于目标文件自身的,连接器需要根据目标文件在最终可执行文件或共享库中的位置,对这些地址进行修正。
合并目标文件:连接器将所有的目标文件和库文件合并成一个单一的可执行文件或共享库。这一步通常包括解决符号冲突,以及将所有目标文件和库文件中的代码和数据按照一定的规则组织在一起。
生成可执行文件或共享库:连接器将合并后的目标文件和库文件生成最终的可执行文件或共享库。在生成可执行文件时,连接器会为程序的入口点设置正确的入口地址,使得程序能够正确地开始执行。

一种特殊的动态链接DLL的方法,
Mingw使用DLL本身作为动态库的引导文件,主要是因为它采用了一种称为"Load-Time Dynamic Linking"的链接方式。这是一种在程序加载时动态链接DLL的方法。当程序启动时,Mingw会解析DLL文件的导出表,并将DLL中的符号地址与程序中的对应符号进行绑定。这样,在程序运行过程中,当需要调用DLL中的函数或使用DLL中的数据时,程序就可以直接通过绑定的地址进行调用,而无需再进行动态链接。
这种链接方式的优势是在程序启动时就已经完成了所有的动态链接操作,因此在运行时可以更快地调用DLL中的函数,避免了运行时的动态链接开销。另外,由于Mingw是一个开源的编译器,它不像MSVC那样受到特定的商业约束和限制。因此,Mingw可以更灵活地处理动态链接的方式,选择将DLL本身作为动态库的引导文件。这种方式在一定程度上简化了编译和链接过程,使得Mingw可以更方便地与开源的DLL库进行集成和使用。

转换为lib引导文件

通常情况下,Mingw生成的DLL可以用于编译链接过程是因为它使用了与MSVC兼容的运行时库,可以与MSVC编译的可执行文件进行链接。而MSVC生成的DLL由于使用了自己的运行时库,所以不能直接与Mingw编译的可执行文件进行链接。如果需要在MSVC编译的项目中使用Mingw生成的DLL,需要进行一些额外的配置和适配工作。
但也要注意,使用 MinGW 编译生成的 DLL 文件通常依赖于 MinGW 的运行时库(例如 mingw32.dll),这些库在没有 MinGW 的系统上可能不存在或不兼容。因此需要确保将这些依赖性包含在生成的 DLL 文件中。这种跨编译器的装换并不是一件简单的事情,不到万不得已,是不建议如此操作的。

接下来我们将尝试将 DllOfMingw 项目生成的DLL转换成可以在mscv下使用的库…

在 D:\Qt\Qt5.12.8\Tools\mingw730_64\bin 下找到 gendef.exe 工具,该工具从 DLL 文件生成 .def 文件。
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
成功生成到了,D:\Qt\Qt5.12.8\Tools\mingw730_64\bin\dllofmingw_d.def,哈哈,肯定还有其他指令参数,没再细究。直接剪切dllofmingw_d.def到我的项目文件目录E:\TestDll\bin_d,进行下一步,
打开 Visual Studio 开发人员命令提示符,使用 lib 命令来生成 .lib 文件。命令如下,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
如上,同时生成了.lib和.exp两种文件,
IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib),IDE集成开发环境,mingw,.a文件,动态库,.lib文件,Qt pro LIBS配置,msvc,编译链接过程
接下来我们新建一个VS项目,动态库部署和代码都没有问题,但是,我并没有成功。编译报错,

#include <stdio.h>
#include "dllofmingw.h"

int main()
{
    DllOfMingw aDll;
    printf("%s", aDll.InvokeTest().c_str());

    system("pause");
    return 0;
}

//ExeOfVS.obj : error LNK2019 : 无法解析的外部符号 "__declspec(dllimport) public: __cdecl DllOfMingw::DllOfMingw(void)" (__imp_ ? ? 0DllOfMingw@@QEAA@XZ),该符号在函数 main 中被引用
//ExeOfVS.obj : error LNK2019 : 无法解析的外部符号 "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl DllOfMingw::InvokeTest(void)" (__imp_ ? InvokeTest@DllOfMingw@@QEAA?AV ? $basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ),该符号在函数 main 中被引用
//..\bin_d\ExeOfVS.exe : fatal error LNK1120 : 2 个无法解析的外部命令

通过上述告警信息,我发现,其中提示的导出符号,与dllofmingw_d.def中的定义,并不一致,

//dllofmingw_d.def
;
; Definition file of dllofmingw_d.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;
LIBRARY "dllofmingw_d.dll"
EXPORTS
_ZN10DllOfMingw10InvokeTestB5cxx11Ev
_ZN10DllOfMingwC1Ev
_ZN10DllOfMingwC2Ev

我没时间继续该问题了,只能暂时放弃。最后这小节,与本文的主要目的,契合度并不大,如果以后有机会将单独开篇继续。文章来源地址https://www.toymoban.com/news/detail-601024.html

到了这里,关于IDE/mingw下动态库(.dll和.a文件)的生成和部署使用(对比MSVC下.dll和.lib)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • VS2019编译生成动态链接库dll的两种方式

     dll项目的默认结构如下:  四个文件的内容因为是默认生成的,不是特别重要, 接下来就是重要的修改部分: 方法一: 修改“pch.h”和“dllmain.cpp”文件,可以参考以下博主链接,但博主的引用部分有些繁琐,文末会介绍我的引用方法,和正常引用外部库步骤是一样的。这

    2023年04月09日
    浏览(46)
  • VS2019 DLL动态链接库生成多个正在运行的Windows应用之间共享的DLL [三]

              本例程演示如何使用 Visual Studio IDE 通过 Microsoft C++ (MSVC) 编写自己的动态链接库 (DLL)。 然后,该演练演示如何从其他 C++ 应用中使用 DLL。 DLL(在基于 UNIX 的操作系统中也称为“共享库”)是最有用的 Windows 组件类型之一 。 可以将其用作共享代码和资源、缩小应

    2024年02月17日
    浏览(39)
  • VSCODE+MSVC+CMAKE配置实践入门:简单编写EXE、LIB和DLL

    目录 EXE: HelloWorld 设置运行环境  编写运行 免设置运行环境的方法 LIB: 加法函数 Add C语言LIB 编译:命令行/task 测试Add.lib DLL: 乘法函数 Mul C语言DLL  编译DLL 测试Mul.dll 生成预编译文件 使用预编译文件 CMAKE 安装CMAKE 使用CMAKE         像VS这样的IDE帮我们包办了很多的事情,同

    2024年02月02日
    浏览(37)
  • visual studio 生成dll文件以及修改输出dll文件名称操作

    Windows系统下Visual Studio可以通过.def文件创建dll。 1.确定需要导出的函数,test.cpp文件中定义如下 2. 添加 .def文件,一般添加到源文件下面。 * 在代码栏下面有一个“模块定义文件”,即我们的.def文件 3.编写test.def文件 文件添加完成,下一步即可设置一些导出规则。 4.在我们的

    2024年02月14日
    浏览(41)
  • Qt6之调用Windows下vc生成的动态链接库dll

    Qt是跨平台工具,显然能和windows的动态库一起使用。 在Windows操作系统上,库以文件的形式存在,并且可以分为动态链接库(DLL) 和静态链接库两种。动态链接库文控以.dll为后缀名,静态链接库文控以.lib为后缀名。不管是动态链接库还是静态链接库,都是向它们的调用者提供变

    2024年02月09日
    浏览(40)
  • 前端项目部署自动检测更新后通知用户刷新页面(前端实现,技术框架vue、js、webpack)——方案一:编译项目时动态生成一个记录版本号的文件

    当我们重新部署前端项目的时候,如果用户一直停留在页面上并未刷新使用,会存在功能使用差异性的问题,因此,当前端部署项目后,需要提醒用户有去重新加载页面。 vue、js、webpack 编译项目时动态生成一个记录版本号的文件 轮询(20s、自己设定时间)这个文件,判断版

    2024年02月02日
    浏览(61)
  • 大数据系列 | 阿里云datav数据可视化(使用json文件生成可视化动态图标)

    简介 DataV 数据可视化是搭建每年天猫双十一作战大屏的幕后功臣,ECharts 是广受数据可视化从业者推崇的开源图表库。从今天开始,DataV 企业版接入了 ECharts 图表组件,当你使用 DataV 搭建可视化项目时,可以轻松地插入 ECharts,这意味着更丰富多样的图表效果,也让编程小白

    2024年02月12日
    浏览(58)
  • 如何查看.dll文件函数接口?(DLL动态链接库)(查看动态链接库、查看接口、查看函数)(Visual Studio的dumpbin工具)(Dependency Walker)

    查看DLL(动态链接库)文件的接口,通常需要使用一些专门的工具。这里有两个比较常见的方法: Dependency Walker 使用Dependency Walker:Dependency Walker是一个免费的实用工具,可以列出DLL文件中的所有导出函数以及它们可能依赖的其他DLL。只需在Dependency Walker中打开想查看的DLL文件

    2024年02月08日
    浏览(52)
  • cmake扩展(2)——windows下动态设置输出文件(dll/exe)版本

    windows下设置文件的版本需要通过VERSIONINFO接口,详情参考VERSIONINFO resource。这里我们根据模板做了一定的修改。 FILEVERSION和PRODUCTVERSION为必填项。内容以\\\',\\\'分隔,输出以\\\'.\\\'分隔(如设置为1,1,3,5,则实际输出版本为1.1.3.5)。可以直接是一整个变量,也可以是多个变量以\\\',\\\'隔开。 而

    2024年02月13日
    浏览(39)
  • Flink on k8s容器日志生成原理及与Yarn部署时的日志生成模式对比

    最近需要将flink由原先部署到Yarn集群切换到kubernetes集群,在切换之后需要熟悉flink on k8s的运行模式。在使用过程中针对日志模块发现,在k8s的容器中,flink的系统日志只有jobmanager.log/taskmanager.log 两个,而当时在使用Yarn集群部署时,flink的日志会有多个,比如:jobmanager.log、jo

    2024年02月07日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包