1. 程序编译成动态库能正常运行而静态库却不行！
我感觉问题不太清楚呢，有如下疑问。
1. 楼主是用的BREW4.0或之前的版本来开发的吗？还是用的最新的Brew MP？
2. 用的模拟器还是下载到设备？
3. 一般不需要自己写makefile 啊，因为开发brew app有很多固有的框架代码，这些一般都由IDE上的插件帮忙生成，而且不需要自己构造命令编译连接的。
我的开发环境是： VC6.0 sp6 + BREW sdk4.0 + ADS1.2 这个可以生成mod下载到手中。
还有另外一个环境：VC2008 + Brew MP 5.0 这个只能在模拟器上测试。
首先，如果不是Brew MP的话，要把程序做成静态的只能和手机的代码一起编译成rom，下载到手机中，这个不能在模拟器上调试。
Brew MP封装了OEM也就是我们无法直接修改手机代码，所以它提供了上层编写静态程序的方法。
所以有些不太清楚你遇到的是那种情况。
一般来说MALLOC挂掉是分配的太大，这种情况很少，除非我故意去测试，真正开发的时候从来没有遇到过，而且跟手机代码一起开发的时候是可以用标准函数malloc的。也可以使用全局变量或静态变量，动态的不可以。
说到makefile，编译mod文件一用自己写，尤其是用VC的时候，brew的插件帮我们写好了，只要点一下就能进行ARM编译和链接，即使是用ADS来编译，也不需要自己写。
有问题再联系吧
2. C/C++编译问题，静态库，动态库。
g++ main.c -L. libalex.so -ltest
3. 求助，依赖的动态库包含静态库，编译报错说找
动态链接库和静态链接库一般是编译集成一系列的接口（函数）
在程序源代码编译完成后通过编译器编译并通过链接器与这些库进行链接
动态链接库与静态链接库的区别在于链接器在进行链接时静态库会被直接编译进程序里
而动态链接库并不会，我们这里将这些链接库称作依赖（动态库和静态库）
程序的运行需要这些依赖，程序在静态链接后该程序本身便已包含该依赖
而动态链接后的程序本身本不包含该依赖，这些依赖需要执行者自行安装进操作系统（动态库、运行时库）
程序运行时会动态地加载这些库
linux上动态库一般的后缀后为.so
静态库一般的后缀为.a
由于静态链接会直接将库编译进程序里所以静态编译后的程序相较于动态链接所要大
这就是因为静态链接会将链接库编译进程序里的原因，所以占用就要大了
出于这种原因，静态库不易于维护与更新，如果链接库中有实现有bug等需要更新则需要更新整个程序，因为静态库被编译进程序中了
但动态库就没有这种情况了，因为动态库是程序运行时动态加载的，所以我们只需要更新动态库而不需要更新所有依赖该库的程序（软件）
另一方面，很多程序的开发都会使用到相同的链接库，也就是很多程序（软件）会有相同的依赖
如果将这些依赖全部静态编译的话将会造成存储资源占用过多而造成资源浪费
而使用动态库的方式这些程序（软件）则可以共享一个链接库，而不需要每个程序都带一个链接库，这样就大大地减少了存储资源占用空间
4. 在连接动态库生成编译可执行文件的时候，用g++编译通过，用gcc报错
Device_Init Query_UsrSum 这两个函数在哪个文件里？
库函数？
如果不是库函数而且不在main.c中的话，需要在编译的时候加上这两个函数所在的文件。
5. VS2010的MFC程序如何调用动态库文件（dll文件）放在system32中仍然编译无法打开d
dll这个东西，只要放到编译时会去访问的任意路径上即可。
比如你现在是Debug，你可以放到Debug文件夹或者工程文件夹；
你现在是Release， 你可以放到Release文件夹或者工程文件放到System32无法访问可能说明你的程序根本不需要去访问System32，虽然这不太可能。
当然我可以认为楼主是在隐式调用dll， 显示调用失败系统不会报错。如果 你是要隐式调用已经知道库在何处和其中函数定义的dll，可以在你的FingerMatch.cpp开始的时候写上：
#ifdef _DEBUG
#pragma comment(lib, "..(路径)fp.lib")
#else
#pragma comment(lib, "..(路径)fp.lib")
#endif
然后包含一下fp.h，这个应该是已经做了。那应该不会有什么问题了。
值得注意的是编译时dll只会打开一次，比如你在Debug文件夹下有一个fp.dll，在工程文件夹下也有一个fp.dll，那么编译时使用的是Debug文件夹下的dll，因为它先被找到。
如果上面说的都没用，那么你显式调用吧
6. FORTRAN中编译动态库的问题出现的错误
看样子，似乎是重复加载了msvcrt.lib，需要仔细检查
7. 当java调用c语言编写的so动态库时，缺少参数时为什么还能调用且不提示错误
那你在C 中这个sub方法里面，把第二个参数打出来看看，是不是空
8. 关于linux下连接动态库问题
gcc编译时，当使用动态库编译可以按照几种写法
1.gcc test.c ./libSDL2-2.so
2.gcc test.c -lSDL2-2
3.gcc test.c -L/home/test -lSDL2-2
一般的编译参数都是按照2或3去写
2写法的含义是从/lib或者/usr/lib目录下寻找名称为SDL2-2的库，即寻找/lib/libSDL2-2.so或者/usr/lib/libSDL2-2.so文件进行链接，当然如果没有动态库就会去找静态库，再没有应该就会在编译时报错
3写法的含义是从-L参数首先从指定的目录中寻找需要链接的库文件，随后再去寻找系统文件夹中是否存在需要的库
1写法的含义是将当前目录下的./libSDL2-2.so.0文件链接进最终文件，因此执行readelf -a a.out后在动态库部分所看到的路径就是./libSDL2-2.so.0，进而在执行文件时仅会从当前目录下寻找libSDL2-2.so.0文件，当执行文件时所在的目录下没有该文件时就会出现找不到库文件的操作
你第二次操作时，因为function.so库文件与a.out文件在同一个目录，同时也是在该目录下执行的ldd操作及运行a.out，a.out在加载动态库时从当前目录下找到了所需要的库文件，此时能够执行成功（ldd命令实质是一个脚本，通过设置环境变量运行动态库链接器来输出所有待链接的动态库）。
你可以试试将a.out拷贝至其他目录再次运行，将出现和第一次操作时一样的现象，找不到function.so文件。
具体的解决方法就是修改编译参数，将./libSDL2-2.so.0修改为-lSDL2-2并将libSDL2-2.so.0文件拷贝至/usr/lib目录下，并且可能因为没有修改链接器的缓存文件（将可能找不到带版本号后缀的动态库），需要在/usr/lib目录下建立一个文件连接（ln -s libSDL2-2.so.0 libSDL2-2.so）或者直接修改名称为libSDL2-2.so