# only if use dumlog audio will build this.
ifeq ($(strip $(BOARD_USES_YUSU_AUDIO)),true)
LOCAL_PATH:= $(call my-dir)
# The audio dump log
include $(CLEAR_VARS)
# shiyanhua
ifeq ($(strip $(XXX_FEATURE_DUMP_LOG)), yes)
LOCAL_CFLAGS += -DXXX_FEATURE_DUMP_LOG
endif
# end
LOCAL_MODULE := libaudio.dump.log
LOCAL_SRC_FILES := $(TOP)/mediatek/platform/mtXXXX/hardware/audio/libaudio.dump.log.a
# LOCAL_MODULE_TAGS := optional
include $(PREBUILD_STATIC_LIBRARY)
#audiohardware
include $(CLEAR_VARS)
......
# shiyanhua
# ifeq ($(strip $(XXX_FEATURE_DUMP_LOG)), yes)
# LOCAL_CFLAGS += -DXXX_FEATURE_DUMP_LOG
# LOCAL_SRC_FILES += aud_drv/AudioDumpLog.cpp.arm
# LOCAL_C_INCLUDES += $(TOP)/mediatek/platform/mtXXXX/hardware/audio/aud_drv
# endif
# end
# LOCAL_LDFLAGS := $(LOCAL_PATH)/libaudio.dump.log.a
# shiyanhua
ifeq ($(strip $(XXX_FEATURE_DUMP_LOG)), yes)
LOCAL_CFLAGS += -DXXX_FEATURE_DUMP_LOG
LOCAL_C_INCLUDES += $(TOP)/mediatek/platform/mtXXXX/hardware/audio/aud_drv
LOCAL_LDFLAGS += $(TOP)/mediatek/platform/mtXXXX/hardware/audio/libaudio.dump.log.a
endif
# end
.......
include $(BUILD_SHARED_LIBRARY)
# The default audio policy, for now still implemented on top of legacy
# policy code
include $(CLEAR_VARS)
......
include $(BUILD_SHARED_LIBRARY)
# The a2dp hardware interface
include $(CLEAR_VARS)
LOCAL_SHARED_LIBRARIES += \
libmedia \
libcutils \
libutils \
libbinder \
libhardware_legacy \
libhardware \
libaudio.primary.default
LOCAL_MODULE := libaudio.a2dp.default
include $(BUILD_SHARED_LIBRARY)
endif
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
NDK 中动态库引用静态库的例子
以下是Android.mk 文件
#这个示例的目的是为了演示如何能够产生两种截然不同的共享库
#
#==================第一个库编译为静态库=====================
LOCAL_PATH:= $(call my-dir)
# first lib, which will be built statically
#
include $(CLEAR_VARS)
LOCAL_MODULE := libtwolib-first
LOCAL_SRC_FILES := first.c
include $(BUILD_STATIC_LIBRARY)
#=======================================================================
#===============第二个库编译为动态库，但依赖于第一个库==============
# second lib, which will depend on and include the first one
#
include $(CLEAR_VARS)
LOCAL_MODULE := libtwolib-second
LOCAL_SRC_FILES := second.c
LOCAL_STATIC_LIBRARIES := libtwolib-first
include $(BUILD_SHARED_LIBRARY)
#include "first.h"
int first(int x, int y)
{
return x + y;
}
#include "first.h"
#include <jni.h>
jint
Java_com_example_twolibs_TwoLibs_add( JNIEnv* env,
jobject this,
jint x,
jint y )
{
return first(x, y);
}
package com.example.twolibs;
import android.app.Activity;
import android.widget.TextView;
import android.os.Bundle;
public class TwoLibs extends Activity
{
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
TextView tv = new TextView(this);
int x = 1000;
int y = 42;
// here, we dynamically load the library at runtime
// before calling the native method.
//
System.loadLibrary("twolib-second");
int z = add(x, y);
tv.setText( "The sum of " + x + " and " + y + " is " + z );
setContentView(tv);
}
public native int add(int x, int y);
}静态库和动态库的区别
库从本质上来说是一种可执行代码的二进制格式，可以被载入内存中执行。库分静态库和动态库两种1. 静态函数库
这类库的名字一般是libxxx.a；利用静态函数库编译成的文件比较大，因为整个 函数库的所有数据都会被整合进目标代码中，他的优点就显而易见了，即编译后的执行程序不需要外部的函数库支持，因为所有使用的函数都已经被编译进去了。当然这也会成为他的缺点，因为如果静态函数库改变了，那么你的程序必须重新编译。
2. 动态函数库
这类库的名字一般是libxxx.so;相对于静态函数库，动态函数库在编译的时候 并没有被编译进目标代码中，你的程序执行到相关函数时才调用该函数库里的相应函数，因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序，而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库。动态函数库的改变并不影响你的程序，所以动态函数库的升级比较方便。
linux系统有几个重要的目录存放相应的函数库，如/lib /usr/lib。
静态库的使用
静态库的操作工具：gcc和ar 命令。
编写及使用静态库
(1)设计库源码 pr1.c 和 pr2.c
[root@billstone make_lib]# cat pr1.c
void print1()
{
printf("This is the first lib src!\n");
}
[root@billstone make_lib]# cat pr2.c
void print2()
{
printf("This is the second src lib!\n");
}
(2) 编译.c 文件
[bill@billstone make_lib]$ cc -O -c pr1.c pr2.c
[bill@billstone make_lib]$ ls -l pr*.o
-rw-rw-r-- 1 bill bill 804 4 月 15 11:11 pr1.o
-rw-rw-r-- 1 bill bill 804 4 月 15 11:11 pr2.o
(3) 链接静态库
为了在编译程序中正确找到库文件,静态库必须按照 lib[name].a 的规则命名,如下例中[name]=pr.
[bill@billstone make_lib]$ ar -rsv libpr.a pr1.o pr2.o
a - pr1.o
a - pr2.o
[bill@billstone make_lib]$ ls -l *.a
-rw-rw-r-- 1 bill bill 1822 4 月 15 11:12 libpr.a
[bill@billstone make_lib]$ ar -t libpr.a
pr1.o
pr2.o
(4) 调用库函数代码 main.c
[bill@billstone make_lib]$ cat main.c
int main()
{
print1();
print2();
return 0;
}
(5) 编译链接选项
-L 及-l 参数放在后面.其中,-L 加载库文件路径,-l 指明库文件名字.
[bill@billstone make_lib]$ gcc -o main main.c -L./ -lpr
[bill@billstone make_lib]$ ls -l main*
-rwxrwxr-x 1 bill bill 11805 4 月 15 11:17 main
-rw-rw-r-- 1 bill bill 50 4 月 15 11:15 main.c
(6)执行目标程序
[bill@billstone make_lib]$ ./main
This is the first lib src!
This is the second src lib!
[bill@billstone make_lib]$
动态库的使用
编写动态库
(1)设计库代码
[bill@billstone make_lib]$ cat pr1.c
int p = 2;
void print(){
printf("This is the first dll src!\n");
}
[bill@billstone make_lib]$
(2)生成动态库
[bill@billstone make_lib]$ gcc -O -fpic -shared -o dl.so pr1.c
[bill@billstone make_lib]$ ls -l *.so
-rwxrwxr-x 1 bill bill 6592 4 月 15 15:19 dl.so
[bill@billstone make_lib]$
动态库的隐式调用
在编译调用库函数代码时指明动态库的位置及名字, 看下面实例
[bill@billstone make_lib]$ cat main.c
int main()
{
print();
return 0;
}
[bill@billstone make_lib]$ gcc -o tdl main.c ./dl.so
[bill@billstone make_lib]$ ./tdl
This is the first dll src!
[bill@billstone make_lib]$
当动态库的位置活名字发生改变时, 程序将无法正常运行; 而动态库取代静态库的好处之一则是通过更新动态库而随时升级库的内容.
动态库的显式调用
显式调用动态库需要四个函数的支持, 函数 dlopen 打开动态库, 函数 dlsym 获取动态库中对象基址, 函数 dlerror 获取显式动态库操作中的错误信息, 函数 doclose 关闭动态库.
[bill@billstone make_lib]$ cat main.c
#include <dlfcn.h>
int main()
{
void *pHandle;
void (*pFunc)(); // 指向函数的指针
int *p;
pHandle = dlopen("./d1.so", RTLD_NOW); // 打开动态库
if(!pHandle){
printf("Can't find d1.so \n");
exit(1);
}
pFunc = (void (*)())dlsym(pHandle, "print"); // 获取库函数 print 的地址
if(pFunc)
pFunc();
else
printf("Can't find function print\n");
p = (int *)dlsym(pHandle, "p"); // 获取库变量 p 的地址
if(p)
printf("p = %d\n", *p);
else
printf("Can't find int p\n");
dlclose(pHandle); // 关闭动态库
return 0;
}
[bill@billstone make_lib]$ gcc -o tds main.c –ld1 –L.
此时还不能立即./tds，因为在动态函数库使用时，会查找/usr/lib、/lib目录下的动态函数库，而此时我们生成的库不在里边。 这个时候有好几种方法可以让他成功运行： 最直接最简单的方法就是把libstr_out.so拉到/usr/lib或/lib中去。 还有一种方法 export LD_LIBRARY_PATH=$(pwd) 另外还可以在/etc/ld.so.conf文件里加入我们生成的库的目录，然后/sbin/ldconfig。 /etc/ld.so.conf是非常重要的一个目录，里面存放的是链接器和加载器搜索共享库时要检查的目录，默认是从/usr/lib /lib中读取的，所以想要顺利运行，我们也可以把我们库的目录加入到这个文件中并执行/sbin/ldconfig 。另外还有个文件需要了解/etc/ld.so.cache,里面保存了常用的动态函数库，且会先把他们加载到内存中，因为内存的访问速度远远大于硬盘的访问速度，这样可以提高软件加载动态函数库的速度了。
库依赖的查看
使用ldd命令来查看执行文件依赖于哪些库。
该命令用于判断某个可执行的 binary 档案含有什么动态函式库。
[root@test root]# ldd [-vdr] [filename]
参数说明：
--version 打印ldd的版本号
-v --verbose 打印所有信息，例如包括符号的版本信息
-d --data-relocs 执行符号重部署，并报告缺少的目标对象（只对ELF格式适用）
-r --function-relocs 对目标对象和函数执行重新部署，并报告缺少的目标对象和函数（只对ELF格式适用）
--help 用法信息。
如果命令行中给定的库名字包含'/'，这个程序的libc5版本将使用它作为库名字；否则它将在标准位置搜索库。运行一个当前目录下的共享库，加前缀"./"。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
android中将静态库链接进动态库成功的例子
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
ARM_PLATFORM := armeabi
#-v7a
LOCAL_MODULE := libf2c
LOCAL_SRC_FILES := lib/libf2c.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := blas_LINUX
LOCAL_SRC_FILES := lib/blas_LINUX.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := lapack_LINUX
LOCAL_SRC_FILES := lib/lapack_LINUX.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := tmglib_LINUX
LOCAL_SRC_FILES := lib/tmglib_LINUX.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_calib3d
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_calib3d.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_contrib
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_contrib.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_core
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_core.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_features2d
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_features2d.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_flann
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_flann.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_highgui
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_highgui.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_imgproc
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_imgproc.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_legacy
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_legacy.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_ml
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_ml.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_objdetect
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_objdetect.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_ts
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_ts.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libopencv_video
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libopencv_video.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := liblibjasper
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/liblibjasper.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := liblibjpeg
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/liblibjpeg.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := liblibpng
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/liblibpng.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := liblibtiff
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/liblibtiff.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libzlib
LOCAL_SRC_FILES := lib/$(ARM_PLATFORM)/libzlib.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_STATIC_LIBRARIES := \
libf2c \
blas_LINUX \
lapack_LINUX \
tmglib_LINUX \
libopencv_contrib \
libopencv_calib3d \
libopencv_objdetect \
libopencv_features2d \
libopencv_video \
libopencv_imgproc \
libopencv_highgui \
libopencv_ml \
libopencv_legacy \
libopencv_flann \
libopencv_core \
liblibjasper \
liblibjpeg \
liblibpng \
liblibtiff \
libzlib
#LOCAL_LDLIBS := -llog -lz -ldl -landroid
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/opencv \
$(LOCAL_PATH)/opencv2 \
$(LOCAL_PATH)/aamsrc \
$(LOCAL_PATH)/test
#LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
LOCAL_MODULE := deteapp
LOCAL_SRC_FILES := \
aamsrc/AAM_Basic.cpp \
aamsrc/AAM_CAM.cpp \
aamsrc/AAM_IC.cpp \
aamsrc/AAM_PAW.cpp \
aamsrc/AAM_PDM.cpp \
aamsrc/AAM_Shape.cpp \
aamsrc/AAM_TDM.cpp \
aamsrc/AAM_Util.cpp \
aamsrc/AAM_VJFaceDetect.cpp \
test/cvTools.cpp \
test/FreqTools.cpp \
test/FaceAlign_Haar.cpp \
test/FaceFeature_GaborF.cpp \
test/LightPrep.cpp \
test/dggev.cpp \
test/Subspace.cpp \
Hopes.cpp
include $(BUILD_SHARED_LIBRARY)
-----------------------------------------------------------------------------------------------------------------------------------------------------------
http://www.2cto.com/kf/201206/136318.html
问题：
昨天调试一个CA库link失败的问题：ca厂商一般提供的都是静态ca库，这样子你直接将其与
你的库link在一起即可使用，但由于apk在ndk中编译器：android-ndk-r6b\arm-linux-androideabi-4.4.3
而ca库使用hisi编译器：arm-eabi-4.4.0_hisi 两者使用的编译不同，所以需要在linux android环境
下将ca静态库打包成动态库，而且用户实现的ca函数将会link失败，生成的动态库将在ndk中使用。
下面是一个简单的测试例子，用于说明一下如何做到相互依赖而编译生成动态库的方法
1、首先编译生成动态库
首先定义头文件：test.h
1. <span style="font-size:16px;">#ifndef XXX_TEST_H___
2. #define XXX_TEST_H___
3.
4. /* 由link的库实现 */
5. extern void testA();
6. extern void testB();
7.
8. /* 由本身库实现而由外部调用 */
9. extern void testC();
10. extern void testD();
11.
12. struct AAInterface{
13. void (*testA)();
14. void (*testB)();
15. };
16.
17. extern void setInterface(struct AAInterface *cb);
18.
19. #endif /* XXX_TEST_H___ */
20. </span>
然后实现文件：testA.c
1. <span style="font-size:16px;">#include <assert.h>
2. #include <stdlib.h>
3. #include <string.h>
4. #include <cutils/log.h>
5. #include "test.h"
6.
7. static struct AAInterface g_aa_interface ;
8.
9. /* 由link的库实现 */
10. extern void testA(){
11. g_aa_interface.testA();
12. }
13.
14. extern void testB(){
15. g_aa_interface.testB();
16. }
17.
18. extern void testCall(){
19. LOGI("testCall 111");
20. testA();
21. LOGI("testCall 222");
22. testB();
23. LOGI("testCall 333");
24. }
25.
26. /* 由本身库实现而由外部调用 */
27. extern void testC(){
28. LOGI("testC call in--->");
29. testCall();
30. LOGI("testC call out<---");
31. }
32.
33. extern void testD(){
34. LOGI("testD call in--->");
35. testCall();
36. LOGI("testD call out<---");
37. }
38.
39. extern void setInterface(struct AAInterface *cb){
40. LOGI("setInterface call in -->");
41. memset((void*)&g_aa_interface,0x00,sizeof(g_aa_interface));
42. g_aa_interface.testA = cb->testA;
43. g_aa_interface.testB = cb->testB;
44. LOGI("setInterface call out <--");
45. }
46. </span>
这里最重要的是利用setInterface接口解决相互link的问题,这就是本质所在。大家一看就明白了，这也是动态
库导出函数的最好方法，一般使用QueryInterface及enumInterface即可，使用结构将
编译方法：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)
LOCAL_MODULE_TAGS := eng
LOCAL_MODULE:= libtestASO
LOCAL_SRC_FILES:= \
testA.c \
LOCAL_SHARED_LIBRARIES := liblog\
LOCAL_C_INCLUDES += \
$(TOP)/frameworks/base/test/testA \
LOCAL_CFLAGS += -D_cplusplus
LOCAL_PRELINK_MODULE := false
include $(BUILD_SHARED_LIBRARY)
2、使用生成的动态库
1. <span style="font-size:16px;">#include <assert.h>
2. #include <stdlib.h>
3. #include <string.h>
4. #include <cutils/log.h>
5. #include <test.h>
6.
7. /* 由link的库实现 */
8. extern void testA(){
9. LOGI("testA call ...");
10. }
11.
12. extern void testB(){
13. LOGI("testB call ...");
14. }
15.
16. int main(void){
17. struct AAInterface *itf = (struct AAInterface*)calloc(1,sizeof(struct AAInterface));
18. itf->testA = testA;
19. itf->testB = testB;
20. setInterface(itf);
21. www.2cto.com
22. testC();
23. testD();
24. return 0;
25. }
26. </span>
ok,知道了如何解决这种相互依赖的方法，解决方法相当解决。。对于这种A需要link B,而B又需要link A的相互关系，这种方法就会起到很好的作用了。
6885
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
