实在是有个问题要问: 如何保证GTK程序的系统独立性？

sinanjj1

我发现升升级，改改locale这些一般的操作都能让gtk程序出现各种错误：依赖的库无法安装，utf－8解析错误。。。。。

在debian下没有这些问题， 不过你给人家装，总得用个好玩的吧，而对于ubuntu而言，最好的解决方法就是从装。。。

恩，百试不爽的方法。。。。。

我试过各种方法解决独立性问题，最理想的静态编译，一直没有成功， 估计是pango库的关系。。。。

看过google earth的方法就是把动态库放当前目录。。。。这个还没实验，那字体文件等咋办？？

哪位大侠有静态编译GTK成功的经验？ 感觉这个问题不除，GTK程序的兼容性就有点问题，一会1.2一会2.0的。。。。。。

sinanjj1

不知道这个方法大家试过没：

环境变量LD_LIBRARY_PATH也可保存目录列表，

装载附加的共享库

在ELF系统上，为了执行一个ELF文件，内核要把控制权交给动态连接器
ld-linux.so.1。

动态连接器执行以下一个步骤完成从程序到进程映象：
1.分析可执行文件中的动态信息section，决定需要哪些库。
2.定位和映象(map)那些共享库，并且分析它们动态信息section
决定是否需要附加的共享库。
3.为可执行程序和那些需要的共享库执行重定位。
4.调用共享库中提供的任何初始化函数并且安排共享库提供的
清除(cleanup)函数在共享库卸栽出进程空间的时候运行。
5.传控制给程序
6.为应用程序提供函数的迟延装定服务
7.为应用程序提供动态转载服务。

环境变量LD_PRELOAD设置共享库名或者用":"把文件名隔开。动态连接器在
任何那些请求的共享库之前把环境变量LD_PRELOAD的共享库装载到进程地址
空间去。例如：

# LD_PRELOAD=./mylibc.so myprog

这里./mylibc.so将第一时间map到程序myprog的空间。因为动态连接器在找
寻标号的时候总是使用第一次碰到的标号，所以我们可以使用LD_PRELOAD来
覆盖标准共享库中的函数。

我们可以这样：
#gcc -c -fPIC -O3 print.c
#gcc -shared print.o -o print.so.1.0
创建自己的共享连接库