http://doc.qt.nokia.com/latest/sharedlibrary.html
The following sections list certain things that should be taken into account when creating shared libraries.
Using Symbols from Shared Libraries
Symbols - functions, variables or classes - contained in shared libraries intended to be used by clients, such as applications or other libraries, must be marked in a special way. These symbols are called public symbols that areexported or made publicly visible.
The remaining symbols should not be visible from the outside. On most platforms, compilers will hide them by default. On some platforms, a special compiler option is required to hide these symbols.
When compiling a shared library, it must be marked forexport. To use the shared library from a client, some platforms may require a special import declaration as well.
Depending on your target platform, Qt provides special macros that contain the necessary definitions:
- Q_DECL_EXPORT must be added to the declarations of symbols used when compiling a shared library.
- Q_DECL_IMPORT must be added to the declarations of symbols used when compiling a client that uses the shared library.
Now, we need to ensure that the right macro is invoked -- whether we compile a share library itself, or just the client using the shared library. Typically, this can be solved by adding a special header.
Let us assume we want to create a shared library calledmysharedlib. A special header for this library,mysharedlib_global.h, looks like this:
#include <QtCore/QtGlobal> #if defined(MYSHAREDLIB_LIBRARY) # define MYSHAREDLIB_EXPORT Q_DECL_EXPORT #else # define MYSHAREDLIB_EXPORT Q_DECL_IMPORT #endif
In the .pro file of the shared library, we add:
DEFINES += MYSHAREDLIB_LIBRARY
In each header of the library, we specify the following:
#include "mysharedlib_global.h" MYSHAREDLIB_EXPORT void foo(); class MYSHAREDLIB_EXPORT MyClass...
This ensures that the right macro is seen by both library and clients. We also use this technique in Qt's sources.
Header File Considerations
Typically, clients will include only the public header files of shared libraries. These libraries might be installed in a different location, when deployed. Therefore, it is important to exclude other internal header files that were used when building the shared library.
For example, the library might provide a class that wraps a hardware device and contains a handle to that device, provided by some 3rd-party library:
#include <footronics/device.h> class MyDevice { private: FOOTRONICS_DEVICE_HANDLE handle; };
A similar situation arises with forms created by Qt Designer when using aggregation or multiple inheritance:
#include "ui_widget.h" class MyWidget : public QWidget { private: Ui::MyWidget m_ui; };
When deploying the library, there should be no dependency to the internal headers footronics/device.h or ui_widget.h.
This can be avoided by making use of the Pointer to implementation idiom described in various C++ programming books. For classes with value semantics, consider using QSharedDataPointer.
Binary compatibility
For clients loading a shared library, to work correctly, the memory layout of the classes being used must match exactly the memory layout of the library version that was used to compile the client. In other words, the library found by the client at runtime must be binary compatible with the version used at compile time.
This is usually not a problem if the client is a self-contained software package that ships all the libraries it needs.
However, if the client application relies on a shared library that belongs to a different installation package or to the operating system, then we need to think of a versioning scheme for shared libraries and decide at which level Binary compatibility is to be maintained. For example, Qt libraries of the same major version number are guaranteed to be binary compatible.
Maintaining Binary compatibility places some restrictions on the changes you can make to the classes. A good explanation can be found at KDE - Policies/Binary Compatibility Issues With C++. These issues should be considered right from the start of library design. We recommend that the principle of Information hiding and thePointer to implementation technique be used wherever possible.
相关推荐
演示Qt静态链接库与动态链接库的创建与使用。环境:windows xp Qt4, MinGW编译器环境。供备忘和参考。
Qt如何使用lib库封装界面一(Qt5动态链接库创建和使用)
实现功能:利用VS2012封装生成动态链接库(.dell和.lib)给QT调用 文件包含:1.VS2012生成动态库工程 2.QT5.5.1调用VS2012动态库工程(注释内含调用具体方法) 3.QT调用运行结果图片
QT中动态链接库的建立,提供一点方法!希望对大家有用!
QT 动态连接库的生成和调用,里面有完整代码和每一步的截图。 生成部分以创建计算器类为例,调用部分为,调用计算机类的add方法,包含了整个dll创建和调用的流程。 仅供参考!大神可绕步!
dll的创建及调用
利用simulink生成动态链接库供VS2015,Qt5.9.2成功调用。
qt4.7调用VS2012创建的动态库, qt调用qt创建的动态库
创建步聚:创建项目-》先lib选项,一直Next,根据实例写库,构建生成.so库。 调用:右键添加外部库-》修改pro文件-》添加头文件-》创建对象-》调用应库函数。
ubuntu下通过两个qt示例以及说明文档来演示创建动态连接库和动态连接使用及注意事项
Qt:显式创建最简单的dll文件 qt dll QLibrary
QT动态链接库(DLL)的创建和调用
DLL在Qt中的创建,DLL在Qt中的显式与隐式的使用
该资源能够使用qt生成dll, 同时又mfc dll的例程,同时有使用qt调用 mfc 和qt dll的例程 。对于 学习使用qt dll很有帮助。
使用vs2015编写的TCP服务端,网络库采用libevent,封装为动态链接库。本例创建了Qt工程,在Qt中调用上述动态链接库。经测试,性能不错。(本例只开了一个线程,可根据业务需要采用多线程或线程池)
但Qt Creator 默认是用动态链接的, 就是可执行程序在运行时需要相应的.dll 文件。我们点击生成的.exe 文件,首 先可能显示“没有找到mingwm10.dll,因此这个应用程序未能启动。重新安装 应用程序可能会修复此问题。...
> 由于直接将在QT中引用MySQL`并不能`直接使用,所以需要将MySQL的动态链接库存放到QT的bin目录下,才可以调用MySQL。QT默认使用`C++11`编译 ``` CONFIG += c++11 ``` > 1,在QT所创建项目中的pro文件中添加sql ...
Winform的MDI父窗体中的子窗体最大化后消除子窗体在父窗体菜单栏中的图标。
通过在windows的虚拟机上的Linux,进行交叉编译 和安装qrencode-3.4.4,生成对应的库,然后将生成的使用tar zcvf 命令打包lib库,将他拷贝至arm设备上qt安装的库下面,创建一个qt的例子,使用动态链接库的方式,将库...
本实例创建了一个不依赖于Qt底层的动态链接库,里面有项目设置和简单的Demo注释,作为模板供自己用,如果你也能用上,就来拿。