DelphiforLinux中应用共享对象库

本文用通俗易懂的语言介绍Linux平台上共享对象库（SO）的基本概念及主要优点 通过剖析在Delphi for Linux中应用SO与在Delphi for Windows中应用DLL的异同 以编程实例讲述了Linux平台的SO库文件的组成 SO库文件的函数重载 特殊编译指令 采用Delphi for Linux创建SO的编程规则 使用前的Linux系统设置 以及在Delphi for Linux中用隐式或显式链接方法装入和使用SO函数的基本方法 经验及技巧 并对应用SO可能出现的问题进行了探讨和分析　　　共享对象库基本概念　　Delphi for Linux是Borland公司推出的基于Linux平台的 面向对象的可视化开发工具 是目前Linux平台上很好的应用开发工具 Delphi for Linux也称Kylix 大家用Kylix开发Linux应用程序时 可能使用过Linux *** 作系统本身带的大量SO文件 SO是一种特殊的运行文件 包含若干方法 对象和资源 它不能直接运行 但可以被Kylix应用程序或其它可执行文件动态调用 SO文件扩展名为 so 编译前源文件扩展名为 dpr 本文所举例子均在Red Hat Linux 及Kylix 环境下调试编译通过 并可正常运行　　　图 是Kylix主程序与SO库的层次关系图 从中可看出使用SO库有以下几个优点　 图 Kylix主程序与SO库的层次关系图　　◆ 多个Kylix程序或它的多个单元文件可通过接口共用一个SO库文件 另一方面 某一个Kylix程序 可通过多个接口使用多个SO库文件 这样 SO变成一种可共用的资源 实现真正的 资源共享 大大缩小了Kylix应用程序的执行代码 增强了软件的可重用性　　　◆ 将SO文件作为Kylix应用程序的公共调用模块设计时 由于其独立于应用程序 软件升级时只需修改SO库文件及编译SO 无需更改及重编译Kylix应用主程序　　　◆ 不仅可使用Kylix编写SO库 还可使用C或C++等常用语言来编写 只要遵循特定的接口规范　　　共享对象库的创建　　 SO库文件的构成　　　　SO库文件和Kylix标准单元文件的内部结构基本相同 也有声明 实现及初始化部分 区别之一在于SO库只是其它程序可以调用的方法(包括函数及过程)集合 区别之二库程序以library关键字而非project开头启动其项目文件 库程序包含有exports语句 其列出要向外部提供的导出函数及过程 下面是SO库文件代码的简单例子 用以说明其构成　　　library MyFirstSO　uses　　　SysUtils classes { Delphi for Windows 中引用类库为Windows }　　function Add (A Char B Char) Integer cdecl overload　begin　　　Result := Ord (A) + Ord (B)　end　function Add (A Integer B Integer) Integer cdecl overload　begin　　　Result := A + B　end　function Double (N Integer) Integer cdecl　　begin　　　Result := N 　end;　　exports　　　Add (A Integer B Integer)　　Add (A Char B Char) name AddChar　　Double　　　 SO库文件中的函数重载　　　　SO库也可以使用重载函数（即多个函数使用相同名称 不同参数） 使用时需在重载的函数声明后标上overload指令 Kylix可以用原名称导出一个重载函数 在exports从句中表示其参数表 若要导出多个重载函数 则要在exports从句中用name字句指定不同名称 以区别重载 这可从上面的例子MyFirstSO中看出 Add是重载函数 为调用时区分 一个用原函数声明Add导出 另一个用AddChar导出　　　 SO库的特殊编译指令　　　　编译后生成的SO库运行文件使用lib前缀和 so扩展名 考虑到实际命名规则与版本和支持符号链 Kylix在Object Pascal语言中引入了几个特殊编译指令 这些在Delphi中没有什么意义 库源文件MyFirstSO dpr编译后产生的执行文件为libMyFirstSO so　　　◆ $SOPREFIX 改变名称前缀 默认为lib（正常库）或bpl（Kylix包） 用前缀区别两种库是因为Linux的库用单一扩展（ so）　　　◆ $SOSUFFIX 在库名与扩展名之间增加文本 指定版本或其它信息　　　◆ $SOVERSION 在扩展名之后增加版本号　　　◆ $SONAME 表示相关符号链名 由编译器自动生成　　　例如 下列代码生成库libsimple so 和符号链libsimple so　　　library simple　uses　　SysUtils Classes　//函数定义省略　　{$SOVERSION　 }　　{$SONAME　 libsimple so }　　　　共享对象库的使用　　Kylix应用程序使用SO库时 可以采用两种方式 一种是隐式链接（Implicit linking） 也称静态装入 另一种是显式链接（Explicit Linking） 也称动态装入 下面分别介绍这两种链接方式的使用方法 技巧及将窗体对象放入SO库的技术　　　 使用前的系统设置　　　　自定义SO库建好后 Kylix应用程序调用时会报错 这是因为Kylix找不到新建库 必须对系统进行相关设置 这与在Delphi for Windows中使用DLL库不同 DLL库建好后只需将编译后的DLL文件放到Delphi主程序目录下即可使用 *** 作步骤如下　　　◆ 将编译好的SO库文件放到Linux系统库目录/lib或/usr/lib下 或者在Linux系统库路径shell变量LD_LIBRARY_PATH中加入自定义SO库文件所在路径　　　◆ 在根用户（root）下 用ldconfig命令刷新库缓冲区　　　◆ 对Kylix执行文件使用ldd命令 查看该程序所关联的SO库　　　 隐式链接　　　　隐式链接是指在应用程序开始执行时就将SO库文件加载到应用程序中 实现隐式链接并不难 只需在应用程序中加入库函数的声明语句及库的external定义从句 则库函数可以和一般局部函数一样使用 比如 要使用libMyFirstSO so中的Add函数 则只要在应用程序中增加下面语句　　　function Add (A Integer B Integer) Integer cdecl　　　external libMyFirstSO so　　　 显式链接　　　　显式链接是应用程序在执行过程中可根据实际需要随时加载SO库文件 也可以随时卸载SO库文件 还可在运行时进行SO库的切换 而这些是隐式链接无法做到的 与隐式链接相比 显式链接具有更大的灵活性　　　在Kylix中 要动态装入库和调用导出函数可以用Delphi仿真代码或自然Linux方法 下面分别介绍这两种方法　　　( )用Delphi仿真代码动态装入　　　　在Windows中动态装入DLL是用Windows API函数—LoadLibrary或Delphi提供的SafeLoadLibrary函数完成的 找到库后 程序调用Windows API函数—GetProcAddress搜索DLL导出函数 若找到匹配 则返回所请求函数指针 并将这个函数指针转换成适当类型和调用 使用完后调用FreeLibrary 从内存中释放库　　　Kylix中使用Pascal RTL仿真函数实现SO库动态装入 下面的例子只列出Kylix应用程序中与动态链接相关部分 而非完整Kylix单元文件代码　　　unit DynaForm;　　interface　　uses　　SysUtils Classes Qcontrols Qforms　type　　　TForm = class(TForm)　　Button : TButton;　　procedure Button Click(Sender: TObject);　　end;　　var　Form TForm　implementation　　{$R XFM}　　type　TComputeInteger = function (x Integer y Integer) Integer cdecl　//调用库函数接口类型定义　　procedure TForm Button Click(Sender TObject)　var Handle Thandle　Compute TputeInteger　begin　　　Handle:＝LoadLibrary( libMyFirstSO so ) //动态装入库　　　if Handle<> then //找到库　　　begin　　Compute:＝TputeInteger(GetProcAddress(Handle Add )　//搜索库函数Add 并返回函数指针　　if Assigned(Compute) then　　　 ShowMessage(IntToStr(Compute( )) //使用库函数　　FreeLibrary(Handle) //释放库　　　end　　　else　　ShowMessage( Library not found )　end　　　( )用Linux自然代码动态装入　　　　也可以使用Libc系统单元中的低级Linux函数 这样可使用更多参数 更好地控制系统 使用的Linux函数分别为dlopen(打开并装入库函数) dlsym(搜索库函数) dlclose(释放库) 因此 上例中调用库的代码变为　　　procedure TForm Button Click(Sender TObject)　var Handle Pointer　Compute TputeInteger　begin　　　Handle:＝dlopen( libMyFirstSO so ) //动态装入库　　　if Handle<>nil then //找到库　　　begin　　Compute:＝TputeInteger(dlsym(Handle Add )　//搜索库函数Add 并返回函数指针　　if Assigned(Compute) then　　　 ShowMessage(IntToStr(Compute( )) //使用库函数　　dlclose(Handle) //释放库　　　end　　　else　　ShowMessage( Library not found )　end　　　( )SO库中窗体对象的使用　　　　除了包含函数和过程的库之外 还可以将Kylix建立的窗体放在共享对象中 这可以是对话框或其它窗体　　　生成新的库对象之后 只要在库源文件的声明部分增加对窗体单元文件 lishixinzhi/Article/program/Delphi/201311/24683

属于混合编程的问题。较全面的介绍一下，不仅限于题主提出的问题。

以下讨论中，Python指它的标准实现，即CPython（虽然不是很严格）

本文分4个部分

C/C++ 调用 Python （基础篇）— 仅讨论Python官方提供的实现方式

Python 调用 C/C++ （基础篇）— 仅讨论Python官方提供的实现方式

C/C++ 调用 Python （高级篇）— 使用 Cython

Python 调用 C/C++ （高级篇）— 使用 SWIG

练习本文中的例子，需要搭建Python扩展开发环境。具体细节见搭建Python扩展开发环境 - 蛇之魅惑 - 知乎专栏

1 C/C++ 调用 Python（基础篇）

Python 本身就是一个C库。你所看到的可执行体python只不过是个stub。真正的python实体在动态链接库里实现，在Windows平台上，这个文件位于 %SystemRoot%\System32\python27dll。

你也可以在自己的程序中调用Python，看起来非常容易：

//my_pythonc

#include <Pythonh>

int main(int argc, char argv[])

{

Py_SetProgramName(argv[0]);

Py_Initialize();

PyRun_SimpleString("print 'Hello Python!'\n");

Py_Finalize();

return 0;

}

在Windows平台下，打开Visual Studio命令提示符，编译命令为

cl my_pythonc -IC:\Python27\include C:\Python27\libs\python27lib

在Linux下编译命令为

gcc my_pythonc -o my_python -I/usr/include/python27/ -lpython27

在Mac OS X 下的编译命令同上

产生可执行文件后，直接运行，结果为输出

Hello Python!

Python库函数PyRun_SimpleString可以执行字符串形式的Python代码。

虽然非常简单，但这段代码除了能用C语言动态生成一些Python代码之外，并没有什么用处。我们需要的是C语言的数据结构能够和Python交互。

下面举个例子，比如说，有一天我们用Python写了一个功能特别强大的函数：

def great_function(a):

return a + 1

接下来要把它包装成C语言的函数。我们期待的C语言的对应函数应该是这样的：

int great_function_from_python(int a) {

int res;

// some magic

return res;

}

首先，复用Python模块得做‘import’，这里也不例外。所以我们把great_function放到一个module里，比如说，这个module名字叫 great_modulepy

接下来就要用C来调用Python了，完整的代码如下：

#include <Pythonh>

int great_function_from_python(int a) {

int res;

PyObject pModule,pFunc;

PyObject pArgs, pValue;

/ import /

pModule = PyImport_Import(PyString_FromString("great_module"));

/ great_modulegreat_function /

pFunc = PyObject_GetAttrString(pModule, "great_function");

/ build args /

pArgs = PyTuple_New(1);

PyTuple_SetItem(pArgs,0, PyInt_FromLong(a));

/ call /

pValue = PyObject_CallObject(pFunc, pArgs);

res = PyInt_AsLong(pValue);

return res;

}

从上述代码可以窥见Python内部运行的方式：

所有Python元素，module、function、tuple、string等等，实际上都是PyObject。C语言里 *** 纵它们，一律使用PyObject 。

Python的类型与C语言类型可以相互转换。Python类型XXX转换为C语言类型YYY要使用PyXXX_AsYYY函数；C类型YYY转换为Python类型XXX要使用PyXXX_FromYYY函数。

也可以创建Python类型的变量，使用PyXXX_New可以创建类型为XXX的变量。

若a是Tuple，则a[i] = b对应于 PyTuple_SetItem(a,i,b)，有理由相信还有一个函数PyTuple_GetItem完成取得某一项的值。

不仅Python语言很优雅，Python的库函数API也非常优雅。

现在我们得到了一个C语言的函数了，可以写一个main测试它

#include <Pythonh>

int great_function_from_python(int a);

int main(int argc, char argv[]) {

Py_Initialize();

printf("%d",great_function_from_python(2));

Py_Finalize();

}

编译的方式就用本节开头使用的方法。

在Linux/Mac OSX运行此示例之前，可能先需要设置环境变量：

bash:

export PYTHONPATH=:$PYTHONPATH

csh:

setenv PYTHONPATH :$PYTHONPATH

2 Python 调用 C/C++（基础篇）

这种做法称为Python扩展。

比如说，我们有一个功能强大的C函数：

int great_function(int a) {

return a + 1;

}

期望在Python里这样使用：

>>> from great_module import great_function

>>> great_function(2)

3

考虑最简单的情况。我们把功能强大的函数放入C文件 great_modulec 中。

#include <Pythonh>

int great_function(int a) {

return a + 1;

}

static PyObject _great_function(PyObject self, PyObject args)

{

int _a;

int res;

if (!PyArg_ParseTuple(args, "i", &_a))

return NULL;

res = great_function(_a);

return PyLong_FromLong(res);

}

static PyMethodDef GreateModuleMethods[] = {

{

"great_function",

_great_function,

METH_VARARGS,

""

},

{NULL, NULL, 0, NULL}

};

PyMODINIT_FUNC initgreat_module(void) {

(void) Py_InitModule("great_module", GreateModuleMethods);

}

除了功能强大的函数great_function外，这个文件中还有以下部分：

包裹函数_great_function。它负责将Python的参数转化为C的参数（PyArg_ParseTuple），调用实际的great_function，并处理great_function的返回值，最终返回给Python环境。

导

出表GreateModuleMethods。它负责告诉Python这个模块里有哪些函数可以被Python调用。导出表的名字可以随便起，每一项有4

个参数：第一个参数是提供给Python环境的函数名称，第二个参数是_great_function，即包裹函数。第三个参数的含义是参数变长，第四个

参数是一个说明性的字符串。导出表总是以{NULL, NULL, 0, NULL}结束。

导出函数initgreat_module。这个的名字不是任取的，是你的module名称添加前缀init。导出函数中将模块名称与导出表进行连接。

在Windows下面，在Visual Studio命令提示符下编译这个文件的命令是

cl /LD great_modulec /o great_modulepyd -IC:\Python27\include C:\Python27\libs\python27lib

/LD 即生成动态链接库。编译成功后在当前目录可以得到 great_modulepyd（实际上是dll）。这个pyd可以在Python环境下直接当作module使用。

在Linux下面，则用gcc编译：

gcc -fPIC -shared great_modulec -o great_moduleso -I/usr/include/python27/ -lpython27

在当前目录下得到great_moduleso，同理可以在Python中直接使用。

本部分参考资料

《Python源码剖析-深度探索动态语言核心技术》是系统介绍CPython实现以及运行原理的优秀教程。

Python 官方文档的这一章详细介绍了C/C++与Python的双向互动Extending and Embedding the Python Interpreter

关于编译环境，本文所述方法仅为出示原理所用。规范的方式如下：3 Building C and C++ Extensions with distutils

作为字典使用的官方参考文档 Python/C API Reference Manual

用以上的方法实现C/C++与Python的混合编程，需要对Python的内部实现有相当的了解。接下来介绍当前较为成熟的技术Cython和SWIG。

3 C/C++ 调用 Python（使用Cython）

在

前面的小节中谈到，Python的数据类型和C的数据类型貌似是有某种“一一对应”的关系的，此外，由于Python（确切的说是CPython）本身是

由C语言实现的，故Python数据类型之间的函数运算也必然与C语言有对应关系。那么，有没有可能“自动”的做替换，把Python代码直接变成C代码

呢？答案是肯定的，这就是Cython主要解决的问题。

安装Cython非常简单。Python 279以上的版本已经自带easy_install：

easy_install -U cython

在Windows环境下依然需要Visual

Studio，由于安装的过程需要编译Cython的源代码，故上述命令需要在Visual

Studio命令提示符下完成。一会儿使用Cython的时候，也需要在Visual

Studio命令提示符下进行 *** 作，这一点和第一部分的要求是一样的。

继续以例子说明：

#great_modulepyx

cdef public great_function(a,index):

return a[index]

这其中有非Python关键字cdef和public。这些关键字属于Cython。由于我们需要在C语言中使用

“编译好的Python代码”，所以得让great_function从外面变得可见，方法就是以“public”修饰。而cdef类似于Python的

def，只有使用cdef才可以使用Cython的关键字public。

这个函数中其他的部分与正常的Python代码是一样的。

接下来编译 great_modulepyx

cython great_modulepyx

得到great_moduleh和great_modulec。打开great_moduleh可以找到这样一句声明：

__PYX_EXTERN_C DL_IMPORT(PyObject) great_function(PyObject , PyObject )

写一个main使用great_function。注意great_function并不规定a是何种类型，它的

功能只是提取a的第index的成员而已，故使用great_function的时候，a可以传入Python

String，也可以传入tuple之类的其他可迭代类型。仍然使用之前提到的类型转换函数PyXXX_FromYYY和PyXXX_AsYYY。

//mainc

#include <Pythonh>

#include "great_moduleh"

int main(int argc, char argv[]) {

PyObject tuple;

Py_Initialize();

initgreat_module();

printf("%s\n",PyString_AsString(

great_function(

PyString_FromString("hello"),

PyInt_FromLong(1)

)

));

tuple = Py_BuildValue("(iis)", 1, 2, "three");

printf("%d\n",PyInt_AsLong(

great_function(

tuple,

PyInt_FromLong(1)

)

));

printf("%s\n",PyString_AsString(

great_function(

tuple,

PyInt_FromLong(2)

)

));

Py_Finalize();

}

编译命令和第一部分相同：

在Windows下编译命令为

cl mainc great_modulec -IC:\Python27\include C:\Python27\libs\python27lib

在Linux下编译命令为

gcc mainc great_modulec -o main -I/usr/include/python27/ -lpython27

这个例子中我们使用了Python的动态类型特性。如果你想指定类型，可以利用Cython的静态类型关键字。例子如下：

#great_modulepyx

cdef public char great_function(const char a,int index):

return a[index]

cython编译后得到的h里，great_function的声明是这样的：

__PYX_EXTERN_C DL_IMPORT(char) great_function(char const , int);

很开心对不对！

这样的话，我们的main函数已经几乎看不到Python的痕迹了：

//mainc

#include <Pythonh>

#include "great_moduleh"

int main(int argc, char argv[]) {

Py_Initialize();

initgreat_module();

printf("%c",great_function("Hello",2));

Py_Finalize();

}

在这一部分的最后我们给一个看似实用的应用（仅限于Windows）：

还是利用刚才的great_modulepyx，准备一个dllmainc：

#include <Pythonh>

#include <Windowsh>

#include "great_moduleh"

extern __declspec(dllexport) int __stdcall _great_function(const char a, int b) {

return great_function(a,b);

}

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,LPVOID lpReserved) {

switch( fdwReason ) {

case DLL_PROCESS_ATTACH:

Py_Initialize();

initgreat_module();

break;

case DLL_PROCESS_DETACH:

Py_Finalize();

break;

}

return TRUE;

}

在Visual Studio命令提示符下编译：

cl /LD dllmainc great_modulec -IC:\Python27\include C:\Python27\libs\python27lib

会得到一个dllmaindll。我们在Excel里面使用它，没错，传说中的Excel与Python混合编程：

参考资料：

Welcome to Cython’s Documentation

4 Python调用C/C++（使用SWIG）

用

C/C++对脚本语言的功能扩展是非常常见的事情，Python也不例外。除了SWIG，市面上还有若干用于Python扩展的工具包，比较知名的还有

BoostPython、SIP等，此外，Cython由于可以直接集成C/C++代码，并方便的生成Python模块，故也可以完成扩展Python

的任务。

答主在这里选用SWIG的一个重要原因是，它不仅可以用于Python，也可以用于其他语言。如今SWIG已经支持C/C++的

好基友Java，主流脚本语言Python、Perl、Ruby、PHP、JavaScript、tcl、Lua，还有Go、C#，以及R。SWIG是基

于配置的，也就是说，原则上一套配置改变不同的编译方法就能适用各种语言（当然，这是理想情况了……）

SWIG的安装方便，有Windows的预编译包，解压即用，绿色健康。主流Linux通常集成swig的包，也可以下载源代码自己编译，SWIG非常小巧，通常安装不会出什么问题。

用SWIG扩展Python，你需要有一个待扩展的C/C++库。这个库有可能是你自己写的，也有可能是某个项目提供的。这里举一个不浮夸的例子：希望在Python中用到SSE4指令集的CRC32指令。

首先打开指令集的文档：https://softwareintelcom/en-us/node/514245

可以看到有6个函数。分析6个函数的原型，其参数和返回值都是简单的整数。于是书写SWIG的配置文件（为了简化起见，未包含2个64位函数）：

/ File: mymodulei /

%module mymodule

%{

#include "nmmintrinh"

%}

int _mm_popcnt_u32(unsigned int v);

unsigned int _mm_crc32_u8 (unsigned int crc, unsigned char v);

unsigned int _mm_crc32_u16(unsigned int crc, unsigned short v);

unsigned int _mm_crc32_u32(unsigned int crc, unsigned int v);

接下来使用SWIG将这个配置文件编译为所谓Python Module Wrapper

swig -python mymodulei

得到一个 mymodule_wrapc和一个mymodulepy。把它编译为Python扩展：

Windows：

cl /LD mymodule_wrapc /o _mymodulepyd -IC:\Python27\include C:\Python27\libs\python27lib

Linux：

gcc -fPIC -shared mymodule_wrapc -o _mymoduleso -I/usr/include/python27/ -lpython27

注意输出文件名前面要加一个下划线。

现在可以立即在Python下使用这个module了：

>>> import mymodule

>>> mymodule_mm_popcnt_u32(10)

2

如果你的程序是动态链接库类型，而不是可执行文件，它就自动会生成一个lib文件（静态库）。

下面来看看如何生成静态库。

我们知道静态库也称档案库，在此档案文件中实际上是收集了一系列的目标文件。这

些目标文件就是由cc(gcc)函数的源代码编译生成的。因此，静态库的生成方法实际上

可以分成两步：

1将各函数代码所在的源文件编译成目录文件。例如，对于myfuncc，可以用如下命令

将其编译成目标文件：

gcc -c myfuncc

当然在有多个源文件时，只需在gcc 命令行中将其分别列上就可以了。

经此一步我休养将能够得到各源文件的目标文件。对上例，将得到myfunco

2将各目标文件收集起来放到一个静态库文件中。这主要借助于ar命令完成，如：

ar r ~/lib/libtesta myfunco

建立动态链接库、并不需要用到其他的工具，借助于gcc命令即可完成。此时需在命令

行中加上-K PIC和-G这两个选项，如下我们可以建立libtest的动态版本：

gcc -K PIC -G -o $HOME/lib/libtestso myfuncc

本来格式很好看的，但因为要贴到这里所以

扭曲了不少，见谅见谅。这里给的是linux下的例子，

但是solaris下的也差不多，如果你发现不同，就给

个详细说明出来，好不好。

ldd filename就可以看到程序用到哪些库。

ld -o OUTPUT /lib/crt0o helloo -lc

ld将输出最终结果文件 OUTPUT ，

用到/lib/crt0o helloo以及libca

libca来自标准库搜索路径，请参看-l选项的讨论

ld的选项顺序任意，可以重复，后面的将覆盖前面的。

gcc -c -fPIC linuxlibc -O3 -o linuxlibo

gcc -shared -Wl,-soname,liblinuxlibso1 \

-O3 -o liblinuxlibso10 linuxlibo

(

ld -m elf_i386 -shared -o liblinuxlibso10 \

-soname liblinuxlibso1 linuxlibo

这个语句产生的文件更小，不知道二者有何区别

-o liblinuxlibso10 这个文件名任意，关键是后面

两个符号连接要正确

当然推荐使用有意义的带版本信息的名字，包括

-soname liblinuxlibso1

)

ln -sf liblinuxlibso10 liblinuxlibso1

(

运行时，dynamic linker根据 -soname \

liblinuxlibso1 去寻找liblinuxlibso1

)

ln -sf liblinuxlibso1 liblinuxlibso

(

编译的最后一个步骤，ld命令根据 -llinuxlib

选项去寻找liblinuxlibso

)

export LD_LIBRARY_PATH=

(

编译时、运行时都需要这个变量的存在

编译时如果不存在这个变量，编译依旧通过，但

用ldd查看会发现没有动态连接信息

运行时如果不存在这个变量，将报告无法找到动态连接库

这个变量如果不用相对路径""，换了运行环境就比较麻烦

export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH

)

gcc -L -lbsd -llinuxlib -O3 -o linuxkiller linuxkillerc

(

-L 指出除标准库搜索路径之外的库搜索路径，如果不指

定，将找不到liblinuxlibso

这个选项并不能代替 LD_LIBRARY_PATH 变量，否则虽然编译通过，

但用ldd linuxkiller的时候会发现没有动态连接信息

)

可以把自己的动态连接库放到/usr/lib或者/lib下去，或者

修改/etc/ldsoconf

然后利用/sbin/ldconfig。具体请man ldconfig

--

发信人: hellguard (小四), 信区: Unix

标 题: Re: help :static library----what's wrong--Thanks

发信站: BBS 水木清华站 (Thu Aug 16 14:22:39 2001)

在 hululu (呼噜噜~回家中) 的大作中提到:

: I am building a static library But I do not know what is

: wrong Below is a sample:

: ttc:

: ＃i nclude <stdioh>

: int func(){

: printf("func test\n");

: return 0;

: }

: iic:

: ＃i nclude <stdioh>

: extern int func();

:

★ 生成静态链接库举例

1 vi demoh

void demo ( void );

vi democ

＃i nclude <stdioh>

＃i nclude "demoh"

void demo ( void )

{

printf( "hello world\n" );

return;

}

2 g++ -Wstrict-prototypes -Wall -Wunused -O3 -c democ -o demoo

file demoo

3 ar -rsv libdemoa demoo

a - demoo

file libdemoa

nm -s libdemoa

ar -tv libdemoa

4 vi sczc

＃i nclude <stdioh>

＃i nclude "demoh"

int main ( int argc, void argv[] )

{

demo();

return 0;

}

5 g++ sczc -L -ldemo -Wstrict-prototypes -Wall -Wunused -O3 -o scz

　　Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。NDK包括了：

　　从C / C++生成原生代码库所需要的工具和build files。

　　将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application packages files，即apk文件）中。

　　支持所有未来Android平台的一些列原生系统头文件和库

　　为何要用到NDK？概括来说主要分为以下几种情况：

　　代码的保护，由于apk的java层代码很容易被反编译，而C/C++库反汇难度较大。

　　在NDK中调用第三方C/C++库，因为大部分的开源库都是用C/C++代码编写的。

　　便于移植，用C/C++写的库可以方便在其他的嵌入式平台上再次使用。

　　Android JNI是什么？和NDK是什么关系？

　　Java Native Interface(JNI)标准是java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口，它使得在 Java 虚拟机(VM) 内部运行的 Java 代码能够与用其它编程语言(如 C、C++和汇编语言)编写的应用程序和库进行交互 *** 作。

　　简单来说，可以认为NDK就是能够方便快捷开发so文件的工具。JNI的过程比较复杂，生成so需要大量 *** 作，而NDK就是简化了这个过程。

　　NDK的异常会不会导致程序Crash，NDK的常见的有哪些类型异常？

　　NDK编译生成的so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会d出“程序xxx无响应，是否立即关闭”之类的提示框。

　　NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（NULL）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生一个无效地址错误。常见的错误类型如下：

　　初始化错误

　　访问错误

　　数组索引访问越界

　　指针对象访问越界

　　访问空指针对象

　　访问无效指针对象

　　迭代器访问越界

　　内存泄露

　　参数错误

　　堆栈溢出

　　类型转换错误

　　数字除0错误

　　NDK错误发生时，我们能拿到什么信息？

　　利用Android NDK开发本地应用的时候，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，首先生成一个错误，然后演示如何通过两种不同的方法，来定位错误的函数名和代码行。

　　首先，看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），看下图：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。

　　如果你看过logcat打印的NDK错误时的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默的选择了无视。

　　“符号化”NDK错误信息的方法

　　其实，只要你细心的查看，再配合Google 提供的工具，完全可以快速的准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。

　　第一种方法：ndk-stack

　　这个命令行工具包含在NDK工具的安装目录，和ndk-build和其他一些常用的NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk

　　–stack命令也有两种方式

　　使用ndk-stack实时分析日志

　　在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：

　　[plain] view

　　plain copy

　　adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

　　当崩溃发生时，会得到如下的信息：

　　[plain] view

　　plain copy

　　 Crash dump:

　　Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:421/JOP40D/1372668680:user/test-keys'

　　pid: 32607, tid: 32607, name: xamplehellojni >>> comexamplehellojni <<<

　　signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000

　　Stack frame #00 pc 00023438 /system/lib/libcso (strlen+72)

　　Stack frame #01 pc 00004de8 /data/app-lib/comexamplehellojni-2/libhello-jniso (std::char_traits<char>::length(char const)+20): Routine std::char_traits<char>::length(char const) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traitsh:229

　　Stack frame #02 pc 000056c8 /data/app-lib/comexamplehellojni-2/libhello-jniso (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const, std::allocator<char> const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_stringc:639

　　Stack frame #03 pc 00004fb4 /data/app-lib/comexamplehellojni-2/libhello-jniso (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jnicpp:69

　　Stack frame #04 pc 00004f58 /data/app-lib/comexamplehellojni-2/libhello-jniso (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jnicpp:61

　　Stack frame #05 pc 000505b9 /system/lib/libdvmso (dvmLoadNativeCode(char const, Object, char)+516)

　　Stack frame #06 pc 00068005 /system/lib/libdvmso

　　Stack frame #07 pc 000278a0 /system/lib/libdvmso

　　Stack frame #08 pc 0002b7fc /system/lib/libdvmso (dvmInterpret(Thread, Method const, JValue)+180)

　　Stack frame #09 pc 00060fe1 /system/lib/libdvmso (dvmCallMethodV(Thread, Method const, Object, bool, JValue, std::__va_list)+272)

　　……（后面略）

　　我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jniso中的报错信息，那么会发现如下关键信息：

　　[plain] view

　　plain copy

　　#03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jnicpp:69

　　#04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jnicpp:61

　　回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？

　　先获取日志，再使用ndk-stack分析

　　这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。

　　[plain] view

　　plain copy

　　adb shell logcat > 1log

　　ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –dump 1log

　　第二种方法：使用addr2line和objdump命令

　　这个方法适用于那些，不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但是可以满足一下程序员的好奇心。

　　先简单说一下这两个命令，在绝大部分的linux发行版本中都能找到他们，如果你的 *** 作系统是linux，而你测试手机使用的是Intel

　　x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。

　　别急，在NDK中自带了适用于各个 *** 作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：

　　[plain] view

　　plain copy

　　/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-48/prebuilt/darwin-x86_64/bin/

　　假设你的电脑是windows， CPU架构为mips，那么你要的工具可能包含在这个目录中：

　　[plain] view

　　plain copy

　　D:\ android-ndk-r9d\toolchains\mipsel-linux-android-48\prebuilt\windows-x86_64\bin\

　　好了言归正传，如何使用这两个工具，下面具体介绍：

　　1 找到日志中的关键函数指针

　　其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。

　　首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc ”开头的行，就可以了。

　　其次要找到属于自己的so文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址

　　2 使用addr2line查找代码位置

　　执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可

　　[plain] view

　　plain copy

　　arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jniso 00004de8 000056c8 00004fb4 00004f58

　　结果如下

　　[plain] view

　　plain copy

　　/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traitsh:229

　　/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_stringc:639

　　/WordSpaces/hello-jni/jni/hello-jnicpp:69

　　/WordSpaces hello-jni/jni/hello-jnicpp:6

　　从addr2line的结果就能看到，我们拿到了我们自己的错误代码的调用关系和行数，在hello-jnicpp的69行和61行（另外两行因为使用的是标准函数，可以忽略掉），结果和ndk-stack是一致的，说明ndk-stack也是通过addr2line来获取代码位置的。

　　3 使用objdump获取函数信息

　　通过addr2line命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，显得不那么“完美”，对于追求极致的程序员来说，这当然是不够的。下面我们就演示怎么来定位函数信息。

　　使用如下命令导出函数表：

　　[plain] view

　　plain copy

　　arm-linux-androideabi-objdump –S obj/local/armeabi/libhello-jniso > helloasm

　　在生成的asm文件中查找刚刚我们定位的两个关键指针00004fb4和00004f58

　　从这两张图可以清楚的看到（要注意的是，在不同的NDK版本和不同的 *** 作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对），这两个指针分别属于willCrash()和JNI_OnLoad()函数，再结合刚才addr2line的结果，那么这两个地址分别对应的信息就是：

　　[plain] view

　　plain copy

　　00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jnicpp:69

　　00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jnicpp:61

　　相当完美，和ndk-stack得到的信息完全一致！

　　使用Testin崩溃分析服务定位NDK错误

　　以上提到的方法，只适合在开发测试期间，如果你的应用或者游戏已经发布上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题，几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。

　　目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，处于领先地位的是国内的Testin和国外的crittercism，其中crittercism需要付费，而且没有专门的中国开发者支持，我们更推荐Testin，其崩溃分析服务是完全免费的。

　　Testin从14版本开始支持NDK的崩溃分析，其最新版本已经升级到17。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等等，SDK将这些信息上报至Testin云服务平台，只要登陆到Testin平台，就可以看到所有用户上报的崩溃信息，包括NDK；并且这些崩溃做过归一化的处理，在不同系统和ROM的版本上打印的信息会略有不同，但是在Testin的网站上这些都做了很好的处理，避免了我们一些重复劳动。

　　上图的红框部分，就是从用户手机上报的，我们自己的so中报错的函数指针地址堆栈信息，就和我们开发时从logcat读到的日志一样，是一些晦涩难懂的指针地址，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传（上文我们提到过的obj/local/目录下的适用于各个CPU架构的so），就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。

　　而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次我们自己编译之后都会改变，很有可能我们刚刚发布一个新版本，这些目录下的so就已经变了，因为开发者会程序的修改程序；在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。所以我们在编译打包完成后记得备份我们的so文件。这时我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。

一、 工具集介绍 （项目地址： https://githubcom/liyuming1978/NativeLibCompression）

安卓压缩工具集提供了一个极为简洁的方法，能够比安卓原有的Zip提供更高压缩比的存储应用内的so文件 （后期版本还可以支持压缩动态加载的jar包，以及游戏资源文件），同时提供了应用内网络更新下载压缩文件的方法，使得应用可以将部分so存储到云端，减小应用的尺寸。

最高节省50%空间！

在云测平台上测试了158款终端，涵盖23到44多个系统版本，100%通过

100%通过测试！

8M文件1s内解压

压缩原理： 压缩工具会把所有的so使用LZMA算法压缩到assert目录，应用在第一次启动的时候，会解压到应用的私有目录下

二、 工具集组成

工具集为一个安装程序，建议安装在默认路径下，安装在program files下在win7可能有读写权限的问题导致一些异常

安装后，你可以看见4个目录，此目录内都含有源码。

安装后的四个目录如下

其中 ApkLibComrepss 为java命令行程序的源码，在此目录的bin子目录中，你可以找到ApkCompressjar ，使用这个文件可以把一个普通的apk文件转换为压缩的apk文件

CompressDemo为一个样例代码，你可以参考这个代码知道如何整合压缩的SDK。

DecRawso是压缩的SDK，你的开发工程需要引用这个SDK，并进行一些源码上的修改，才能整合压缩的功能

RawsoCreator为windows下的转换工具， 这个工具一般无需使用， 仅仅在调试和二次开发压缩SDK的时候使用。

三、 如何整合压缩SDK

打开CompressDemo，我们以这个工程为例子讲解如何整合压缩SDK

1 首先需要引入DecRawso工程

2 然后需要在你的工程内最初始的地方调用DecRawsoNewInstance。在此demo工程内，是在MainActivityjava的OnCreate内调用了此方法， 此方法是创建了一个解压的唯一实例。注意：此方法是异步的，所以你可以传入一个handler接受异步解码完成的消息，如果同时传入参数showProgress=true，SDK内会产生一个进度对话框以阻塞主进程。不推荐使用DecRawsoNewInstance(mContext,null,false);的方式，此方式不接受任何消息，且无进度对话框，解压会在后台自动完成，并且在应用第一次load so的时候阻塞直到后台解压完成。所以如果阻塞时间过长，可能会导致应用无响应。

3 修改load so文件的方法：所有的Systemloadlibrary()改为 Systemload(DecRawsoGetInstance()GetPath(“"));

新版本， 这步可以省略了，sdk会修改system的libaray加载路径，一般情况下，系统升级不会出问题 （非正规代码，小概率会随android升级修改新的代码），如果方便的话，还是采用Systemload(DecRawsoGetInstance()GetPath(“"))

经过这几个简单的步骤，压缩的SDK已经整合到工程内了。

四、 如何压缩发布APK

使用ApkCompressjar压缩发布APK。 此工具为命令行工具。一般的此命令使用方式为：在命令行运行ComPressApkjar-a C:/my/testapk -k c:/key ### alias -x86http://wwwtestcom （也可以运行 java –jarComPressApkjar ）

-a 后面跟apk路径名， 可以不是全路径

-k 后面是签名文件[key storepasskeypass alias name] ，key可以不是全路径名 (name 如果不写， 默认就是CERT)

-x86 表示需要存储x86库文件在云端， 后面跟以http://开头的链接，最后实际的存储位置应该为 http://wwwtestcom/cloudrawso_x86

命令执行完以后， 会生成test_CompressAlignapk 这个apk就是压缩后的apk

五、 开发模式和压缩模式

为了方便开发，在实现开发的过程中（修改了源码支持压缩后），也可以不压缩so，apk也可以正常运行，压缩的SDK内部会自动判断是否有压缩包， 如果没有压缩包，则加载的路径恢复成android默认的路径。所以最方便的开发是，先整合代码，在开发过程中和原来一样开发（不压缩），在发布的时候才压缩apk

六、 X86和ARM库混合调用

在实现开发过程中，可能会有某些第三方库确实没有x86版本，通常情况下ISV并不在x86目录下放置arm的第三方库，那么在实际运行过程中会导致缺库现象的发生。在缺库的情况下，压缩的SDK会在x86设备上自动解压arm的压缩包，避免缺库现象的发生。（只有真正加载了缺失的库才是缺库，库文件不一致并不一定就是缺库）

但是显然这样会导致运行的低效率，如果在第三方so和x86的库完全没有相互引用的情况下（也就是说这些库都是java层使用JNI调用的，在native层没有相互调用），可以拷贝arm的第三方库到x86目录下，这样就不会出现缺库的情况。当然这种情况会导致arm库多余的拷贝，在以前的zip压缩情况下，会使得压缩包变大，但是在新的LZMA压缩情况下，库大小完全不会增大，因为LZMA压缩由于字典比较大，能够尽可能的压缩关联的几个文件，如果文件完全相同，LZMA的压缩会和单个文件基本一致。

objdump 是 gcc 套件中用来查看 ELF 文件的工具，具体详细用法不进行介绍，此处只讲解如何进行一个动态库和静态库中导出函数的查看。

1) 查看依赖项：objdump -x xxxso | grep "NEEDED" 。下面是我查看 libsf_modbus_preproceso 时的输出截图：

2) 查看动态符号表： objdump -T xxxso 。假如想知道 xxxso 中是否导出了符号 yyy ，那么命令为 objdump -T xxxso | grep "yyy" 。下面是我查看 libsf_modbus_preproceso 时的输出截图：

3) 查看符号表： objdump -t xxxso 。-T 和 -t 选项在于 -T 只能查看动态符号，如库导出的函数和引用其他库的函数，而 -t 可以查看所有的符号，包括数据段的符号。下面是我查看 libsf_modbus_preproceso 时的输出截图：