如何在Linux下来调用用dll库？

微软表示：我们的编译器并没有考虑生成的机器码还要能够让linux运行……开个玩笑，这个问题你得先了解编译原理，windows下的库有两种，一种是native code，这种就别想了，它之所以能够在windows上运行，当然是因为编译器把它们编译成了windows *** 作系统能够识别的机器码组织形式（严谨地来说，是链接器和加载器的不同，以及各自的系统调用压根就没有互映射性，导致了linux不能使用它们）；第二种是.net平台编译出来的类库，这个是生成了中间语言（IL），跟java一样，原则上是跨平台的，不过很多年以来，它只是原则上而已，从来就没跨过。不过现在的好消息是，.net standard已经在包括linux之内的若干 *** 作系统上完成了实现，所以如果你在.net平台上编写一个完全符合.net standard库的dll的话，它是可以跑在linux上的（严格来说，是某些非常新的linux发行版），这就是大名鼎鼎的.net core，也是微软目前在软件开发方向上大力投入的开源社区项目。所以总的来说，微软还是充分考虑到你的这种应用需求的。如果你确实想完成把windows下的应用程序改到linux下面来运行，.net core是目前最好的选择（因为还有个叫Mono的哥们也在做同样的事儿，你同样可以参考）

LinuxC++编写线程安全库dll的方法：

1、动态库只有一个导出函数。

这种情况下编写函数时，只需要考虑不要有冲突的全局数据就可以了。这里的全局数据包括了在堆中分配的数据块和静态全局变量等。如果存在这样的全局数据，那么进程中的不同线程访问这个函数就会造成冲突。

2、动态库导出了多个函数，而且多个函数间存在数据传递。

一般DLL都导出多个函数，一个初始化，一个资源释放，其他为核心功能函数。这些函数间极有可能发生数据传递。如果一个初始化函数是在线程A中调用的，而核心功能函数是在线程B中调用的，那么线程A初始化函数的资源就无法对应线程B中的核心功能，此外还有核心功能函数间的数据传递，这样的DLL就不是线程安全的，必然导致错误。

解决办法是由用户（即使用DLL的人）保证这些导出函数是在一个线程中调用。但这样会很大程度上限制接口的设计和用户的使用自由度。所以最好的方法是函数只管自己的线程安全，不同函数传递数据用动态TLS，线程局部存储。

3、限制访问DLL中某一函数的线程数目。

对于DLL中的某一个函数的访问线程数目是有限制的，超过了限制其他线程就得等一定的时间，一定的时间过后如果还不能得到执行机会，那就返回超时。这样的设计对用户来说是友好的，而且很实用，有的商业程序确实是按照允许用户访问的通道数目来计价的。

对DLL中的函数做这样的一个封装，一般是简单的待用Semaphore信号量，来解决。DLL初始化时调用CreateSemaphore函数对信号量进行初始化，其原型如下：

HANDLE CreateSemaphore(

LPSECURITY_ATTRIBUTES lpSemaphoreAttributes,

// pointer to security attributes

LONG lInitialCount, // initial count

LONG lMaximumCount, // maximum count

LPCTSTR lpName // pointer to semaphore-object name

)

对于信号量，它每WaitForSingleObject一次（当然是要进入），其状态值（一个整数）就减1，使用完ReleaseSemaphore其状态值就加1，当其状态值为0时信号量就由有信号变为无信号。利用信号量的这一特性，我们在初始化时将信号量的初始值（第2个参数）设置为限制的线程访问数目。在要限制访问线程数目的函数内部，通过调用WaitForSingleOject获取控制权，并指定一个等待时间（这个由配置文件指定），根据情况超时返回，使用完ReleaseSemaphore释放对占用，让其他线程可以调用这个函数。

4、多进程情况下的多线程安全DLL。

LL是可以被多个进行加载并调用的。那就是说如果我们只对一个进程进行了限制，那么在多进程调用的情况下，这样的限制被轻易攻破。

我们都知道，Semaphore信号量属于内核对象，也就是说其可以被多进程共享访问，也就说，如果我们给一个Semaphore指定了一个名字，在另一个进程中，我们只要调用OpenSemaphore函数用同一名字打开信号量就可以访问了。这样问题就解决了？

现实情况是，多进程情况下，一般不是简单的多进程共享一个Semaphore就可以了。多进程间需要互通很多信息。一般的解决办法是，采用共享数据段。

#pragma data_seg("share")

int share_data

#pragma data_seg()

#pragma comment(linker,"/SECTION:share, RWS")

通过pragam编译器指令生成了一个名叫share的共享数据段，这样对于变量share_data就可以多进程共享的了。如果要多进程间交换数据，只要在data_seg中添加数据定义即可。

Linux 系统，也同样面临和Window一样的问题，如何控制动态库的多个版本问题。Window之前没有处理好，为此专门有个名词来形容这个问题 “Dll hell”，其严重影响软件的升级和维护。 Dll hell 是指windows 上动态库新版本覆盖旧版本，但是却不兼容老版本。常常发生在程序升级之后，动态库更新，原有程序运行不起来；或者装新软件，但是已有的软件运行不起来。 同样Linux *** 作系统，也有同样的问题，那么它是怎么解决的呢？

Linux 为解决这个问题，引入了一套机制，如果遵守这个机制来做，就可以避免这个问题。 但是这只事一个约定，不是强制的。但是建议遵守这个约定，否则同样也会出现 Linux 版的Dll hell 问题。 下面来介绍一个这个机制。 这个机制是通过文件名，来控制dll （shared library） 的版本。

Linux 上的Dll ，叫shared library，其有三个名字，分别有不同的目的。

第一个是共享库本身的文件名（real name），其通常包含版本号，常常是是这样： libmath.so.1.1.1234 。 lib是Linux 上的库的约定前缀，math 是共享库名字，so 是共享库的后缀名，1.1.1234的是共享库的版本号，其主版本号+小版本号+build号。主版本号，代表当前动态库的版本，如果动态库的接口有变化，那么这个版本号就要加1；后面的两个版本号（小版本号 和 build 号）是告诉你详细的信息，比如为一个hot-fix 而生成的一个版本，其小版本号加1，build号也应有变化。 这个文件名包含共享库的代码。

第二个是动态库的soname（ Short for shared object name），其是应用程序加载dll 时候，其寻找共享库用的文件名。其格式为

lib + math+.so + ( major version number)

其只包含major version number，换句话说，也就是只要其接口没有变，应用程序都可以用，不管你其后minor build version or build version。

问题来了，程序运行时怎么通过soname 找个real name？ Soname 存在哪里？如果与real name 关联起来？什么时候存的？

这就是接下来要介绍的第三个共享库的名字，link name，顾名思义，就是在编译过程，link 阶段用的文件名。 其将sonmae 和real name 关联起来。

第三个名字，共享库的连接名（link name），是专门为build 阶段连接而用的名字。这个名字就是lib + math +.so ,比如libmath.so。其是不带任何版本信息的。在共享库编译过程中，连接（link） 阶段，编译器将生成一个共享库及real name，同时将共享库的soname，写在共享库文件里的文件头里面。可以用命令 readelf -d sharelibrary 去查看。

---