㈠ VC程序调用动态库,编译时候也跟着编译动态库
不太清楚你的工程是如何建立的，想必一个工程是生成动态链接库，另一个是调用程序EXE了。由于VC动态库有两种形式，Regular和Extended两种，其中一种能导出类，另一种只能导出变量和函数。如果导出的是类，你在编译EXE文件时自然需要用到类得声明文件，即你前面所说的动态库本身所引用的文件。如果导出的是函数或变量，有可能出现的情况是：一般为了代码的重用性，把需要导出的函数或变量单独放在一个头文件中，用一个宏控制其导入、导出。编译动态库时，宏定义为导出，编译EXE时，宏变为导入，这个头文件为两者共用。如果不小心在这个头文件中包含了其他头文件，也可能出现你说的情况。如果动态库调用直接采用函数入口地址的方法，则什么都不用声明，当然，只适用于导出函数与变量的情形。
㈡ linux动态库问题
1、虽然动态库有点浪费内存，但是动态库最大的作用是：减少占用磁盘空间，减少开发时的编译陪仔时间，而不是你想的编译速度慢。因为采用了动态库，所以如果我修改了动态库，我只需要编译动态库。而如果采用了静态库，如果修改了静态库，那么，所有用了该静态库的程序和静态库都必须重新编译。而且gcc不是扫描整个libc.so文件。因为so文件里有符号表，哪个符号在哪个.o文件里，只要扫描符号表就知道了，而且由于他不需要从so文件中拷贝使用的函数，从某种意义上来说编译速度比静态库更快。
2、动态库的加载采拆亮用写时拷贝技术，即：只有当我用这个函数的时候我才把该函数部分拷贝过来，芦御汪它不会拷贝整个so文件，只会拷贝需要的部分。
㈢ 怎么重新编译android 下面的动态库
使用动态库来编译动态库
A项目的android.mk文件如下:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := testa
LOCAL_SRC_FILES := testa.c
include $(BUILD_SHARED_LIBRARY)
生成的libtesta.so加入到E:\workspace\android-ndk-r8e\platforms\android-8\arch-arm\usr\lib\下面
项目B的文件目录结构如下:
jni
jni/jni/
jni/prebuilt/
jni目录下的mk文件如下:
include $(all-subdir-makefiles)
jni/prebuilt目录下的mk文件如下:
LOCAL_PATH := $(call my-dir)
#include $(CLEAR_VARS)
LOCAL_MODULE := libtesta
LOCAL_SRC_FILES := libtesta.so
include $(PREBUILT_SHARED_LIBRARY)
同时把libtesta.so也放入该目录下.
jni/jni目录下的mk文件内容:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -ltesta
LOCAL_MODULE := testb
LOCAL_SRC_FILES := testb.c
include $(BUILD_SHARED_LIBRARY)
这样生成libtestb.so文件, 同时eclipse在打包时会把libtesta.so, libtestb.so都加入到apk文件中，如果没有prebuilt那一步，那么在打包时会漏掉libtesta.so, 但编译会通过,因为编译读取的是编译系统的库文件目录(LOCAL_LDLIBS := -ltesta), 这点需要注意
java代码:
System.loadLibrary("testa");
System.loadLibrary("testb");
注意先后关系
㈣ android已有动态库怎么编译静态库
在eclipse工程目录下建立一空码个jni的文件夹
在jni文件夹中建立Android.mk和Application.mk文件
Android.mk文件：
Android提供的一种makefile文件，用来指定诸如编译生成so库名、引用的头文件目录、需要编卖凯译的.c/.cpp文件和.a静态库文件等。详见附件中的Android.mk。
Application.mk文件：
定义了项目的一些细节，比如APP_ABI := x86(编译X86平台库)、APP_PLATFORM := android-9(使用android-9以上的平台库)。
NDK 编译和使用静态库、动态库
情况一：编译静态库
情况二：编译动态库
情况三：编译动态库+静态库
情况四：已有第三方静态库（动态库），编译静态库（动态库）
默认所有代码和文件在$project/jni下，否则特殊说明。
情况一：编译静态库
文件Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_STATIC_LIBRARY)
文件Application.mk:
APP_MODULES :=hello-jni
情况二：编译动态库
文件Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
情况三：编译动态库+静态库
文件Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := mylib_static
LOCAL_SRC_FILES := src.c
include $(BUILD_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := mylib_shared
LOCAL_SRC_FILES := src2.c
LOCAL_STATIC_LIBRARIES := mylib_static
include $(BUILD_SHARED_LIBRARY)
情况四：已有第三方静态库(动态库)，编译静态库(动态库)
文件Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := thirdlib1 # name it whatever
LOCAL_SRC_FILES := $(TARGET_ARCH_ABI)/libthird1.a # or $(so_path)/libthird1.so
#LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_STATIC_LIBRARY) #or PREBUILT_SHARED_LIBRARY
include $(CLEAR_VARS)
LOCAL_MODULE := mylib_use_thirdlib
LOCAL_SRC_FILES := src.c
LOCAL_STATIC_LIBRARIES := thirdlib1 #or LOCAL_SHARED_LIBRARY
include $(BUILD_SHARED_LIBRARY) #如果编译静态库，需要Application.mk
用cd命令移至jni目录，运行/mnt/500G/public/NDK/android-ndk-r7b/ndk-build命令，这时命令行中可能会出现编译错误，比如头文件找不到，函数找不到等等，细心找找就能改掉。
编译成功后，在工中亏唤程目录下libs/x86中就会生成你想要的.so库。
㈤ 在redhat linux5.4里 替换动态库后，编译成功，但用ldd查看程序，显示此库找不到
呵呵友模，
1.将该路含告乎径添加到/etc/ld.so.conf的谈悉最后一行
2.ldconfig -v
应该就可以了。
㈥ qt动态库编译,是否只要声明
qt动态库编译,是否只要声明
这里的动态的意思汪耐应该是模块代码是动态加载的
而不是随着应用程序一起编译
只要动态库里的函数接口不变
应用程序就无需重新编译
只键橘需将动态库重新编译后替换掉旧的动态库即可
如果动态库的函数接口困亮春有变动
那么应用程序就要重新编译发布
这也是我的个人理解~~~
㈦ 动态库怎么编译
# 声称动代连接库模山销，假设名唯轮称为libtest.so gcc x.c y.c z.c -fPIC -shared -o libtest.so # 将main.c和动态连接库进行连接生成可执行文件 gcc main.c -L. -ltest -o main # 输出LD_LIBRARY_PATH环境变量，一边动态库装载旦游器能够找到需要的动态库 e...
㈧ 依赖的dll更新后什么情况下需要重新编译主程序
有的网站后台代码既有aspx又有CS文件，而且更改CS文件后不需要重新编译，网站直接就改变了，是有好多这样的网站。 主要的原因是：网站编译，可以是整站编译，也可以不编译的。把所有源代码，放在相应目录，也是可以正常运行的，
㈨ 动态库链接编译
这里的动态的意思应该是模块代码是动态加载的
而不是随着应用程序一起编译
只要动态库里的函数接口不变
应用程序就无需重新编译
只需将动态库重新编译后替换掉旧的动态库即可
如果动态库的函数接口有变动
那么应用程序就要重新编译发布
这也是我的个人理解~~~
㈩ linux 下如何将动态链接库.so进行反编译后,换编译器重新编译
程序能不能正常运行取决于程序和动态库之间的ABI是否兼容。只要ABI兼容那么编译器版本就没有影响。高版本的编译器同样可以使用低版本的ABI来生成目标代码，但这个问题要具体分析。你解决问题的思路完全不对。