目标：把pbp1.0的java包和native移到GEM中，并使GEM在新的虚拟机上正常运行
背景：GEM(1)有一堆java包和native函数，pbp1.0是虚拟机和JAVA基本包，要将pbp1.0的虚拟机移走只用它的JAVA基本包和native函数。
问题：在将GEM和pbp1.0的native函数生成一个动态库后在程序里System.loadLibrary()无法加载，报java.lang.UnsatisfiedLinkError
解决过程：
1，理论
我们知道，JAVA调用native函数时，必须通过System.loadLibrary()或System.load将其native函数所在动态库加载到虚拟机。并在运行时指明-Djava.library.path或-Dsun.boot.library.path，将其指向包含有native函数的动态库所在位置。
2，实施
我按这个步骤操作完成后就是无法加载我生成的动态库libgem.so,这个库用到的其他动态库包括：rt,pthread,freetype,dl,directfb,而directfb用到的动态库有rt,dl,pthread,freetype,jpeg,png，这些库除了directfb要生成外其余都在/lib目录下存在。
3，思路
先写了一个Hello的测试用例。发现在native里所使用到其他动态库时，无论是否存在于相关目录，仍然无法加载。然后经过修改编译选项，把所使用到的动态库连动态连接进目标库，如下：
$(GCC) -fPIC -shared -o libdirectfb.so ... -lpng -ljpeg -lpthread -lrt -ldl, -lfreetype
经过这么一个修改后，directfb可以加载。
这也说明System.loadLibrary()所加载的动态库所引用的所有符号都要能找到。如果有一个无法找到将无法加载。可以写一个空的main()函数，对你的动态库进行连接，如果动态库里所引用的符号在指定的动态库和本身找到不到则无法编译通过，那么这个动态库也肯定加载不了。
4,问题解决
按照这个思路，对libgem.so的编译Makefile做相应修改后，问题解决!并在LD_LIBRARY_PATH加入动态库所在目录。
(1) MHP (Multimedia Home Platform) was developed by the DVB Project as the world's first open standard for interactive television. It is a Java-based environment which defines a generic interface between interactive digital applications and the terminals on which those applications execute. MHP was designed to run on DVB platforms but there was a demand to extend the interoperability it offers to other digital television platforms. This demand gave rise to GEM, or Globally Executable MHP, a framework which allows other organisations to define specifications based on MHP.