Linux 运行的时候，是如何管理共享库(*.so)的？在 Linux 下面，共享库的寻找和加载是由 /lib/ld.so 实现的。 ld.so 在标准路经(/lib, /usr/lib) 中寻找应用程序用到的共享库。
但是，如果需要用到的共享库在非标准路经，ld.so 怎么找到它呢？
目前，Linux 通用的做法是将非标准路经加入 /etc/ld.so.conf，然后运行 ldconfig 生成 /etc/ld.so.cache。 ld.so 加载共享库的时候，会从 ld.so.cache 查找。
传统上， Linux 的先辈 Unix 还有一个环境变量 - LD_LIBRARY_PATH 来处理非标准路经的共享库。ld.so 加载共享库的时候，也会查找这个变量所设置的路经。但是，有不少声音主张要避免使用 LD_LIBRARY_PATH 变量，尤其是作为全局变量。这些声音是：
* LD_LIBRARY_PATH is not the answer - http://prefetch.net/articles/linkers.badldlibrary.html
* Why LD_LIBRARY_PATH is bad - http://xahlee.org/UnixResource_dir/_/ldpath.html
* LD_LIBRARY_PATH - just say no - http://blogs.sun.com/rie/date/20040710
解决这一问题的另一方法是在编译的时候通过 -R<path> 选项指定 run-time path。
--
每一个不曾起舞的日子都是对生命的辜负。
17 Sept 2007
15 Sept 2007
cross-compile 时的 libtool 陷阱
做了不少的 cross-compiling 了，但是 libtool 是个头痛的问题。autconf/automake 这一套本来是为了方便编译的，现在却给交叉编译带来了新的。关于这个话题，下面两篇文章讲得比较明白：
或许，在需要的时候避免使用 libtool 也是个解决方案？
[Update@Thu Jan 17 17:35:37 CST 2008]
工作中，cross-compile 一块的惯常做法还是 bob 的 blog ：《如何交叉编译 应用程序，技巧，注意事项》里提到的方法：先通过 configure 生成 编译 package 的 Makefile，然后手动修改这些 Makefile。这是一种土方法，但却成了我们开发中的传统，力气活，很累人，已经有好几次到了崩溃的边缘。我很讨厌这种方法，因为所有这些的工作都是一次性的。如果一个 package 需要跟随 upstream 升级，你就必须从头再来一遍；如果自己做了一些修改，那还要把改动合过去，跟麻烦。
基于上述原因，我一直寻找一种可以快速跟随 upstream 并管理自己 patch 的方案，虽然由于种种原因很难在工作上使用，但我至少可以体会“亲手打造”一套系统的畅快淋漓。OpenMoko 的方法就不错，值得学习。
--
每一个不曾起舞的日子都是对生命的辜负。
或许，在需要的时候避免使用 libtool 也是个解决方案？
[Update@Thu Jan 17 17:35:37 CST 2008]
工作中，cross-compile 一块的惯常做法还是 bob 的 blog ：《如何交叉编译 应用程序，技巧，注意事项》里提到的方法：先通过 configure 生成 编译 package 的 Makefile，然后手动修改这些 Makefile。这是一种土方法，但却成了我们开发中的传统，力气活，很累人，已经有好几次到了崩溃的边缘。我很讨厌这种方法，因为所有这些的工作都是一次性的。如果一个 package 需要跟随 upstream 升级，你就必须从头再来一遍；如果自己做了一些修改，那还要把改动合过去，跟麻烦。
基于上述原因，我一直寻找一种可以快速跟随 upstream 并管理自己 patch 的方案，虽然由于种种原因很难在工作上使用，但我至少可以体会“亲手打造”一套系统的畅快淋漓。OpenMoko 的方法就不错，值得学习。
--
每一个不曾起舞的日子都是对生命的辜负。
基于 Linux 的 boot loader - kboot
kboot 本质上是个小型的 Linux 系统，但功能却是个 boot loader。
可能的使用领域是普通的 boot loader 功能不够用，或者不好重烧原有的 boot loader。具体预期情景：要 hack OpenEZX， 原来的 boot loader 是 blob，并不是为 hacking 准备的，因此用起来很不方便，但是重烧它又用让设备 over 的风险。这时，我们可以通过 blob 启动一个 kboot，然后做我们期望的事情。事实上，对于 hacking openezx，已经用人提议过通过 blob 再起一个自己可以定制的 blob。
备用资料：
* kboot 初探与模拟验证 - http://orzlab.blogspot.com/2007/06/kboot.html
--
每一个不曾起舞的日子都是对生命的辜负。
可能的使用领域是普通的 boot loader 功能不够用，或者不好重烧原有的 boot loader。具体预期情景：要 hack OpenEZX， 原来的 boot loader 是 blob，并不是为 hacking 准备的，因此用起来很不方便，但是重烧它又用让设备 over 的风险。这时，我们可以通过 blob 启动一个 kboot，然后做我们期望的事情。事实上，对于 hacking openezx，已经用人提议过通过 blob 再起一个自己可以定制的 blob。
备用资料：
* kboot 初探与模拟验证 - http://orzlab.blogspot.com/2007/06/kboot.html
--
每一个不曾起舞的日子都是对生命的辜负。
4 Sept 2007
SkypeOut 的收费
参数：
* Skype Out 接通费：￥0.39/次
* Skype Out 通话费：￥0.19/分钟
* Skype Out 接通费：￥0.39/次
* Skype Out 通话费：￥0.19/分钟
Time(m) Fee(Y/m)
1 0.580000
2 0.385000
3 0.320000
4 0.287500
5 0.268000
6 0.255000
7 0.245714
8 0.238750
9 0.233333
10 0.229000
15 0.216000
20 0.209500
25 0.205600
30 0.203000
35 0.201143
40 0.199750
45 0.198667
50 0.197800
55 0.197091
60 0.196500
--
每一个不曾起舞的日子都是对生命的辜负。
Subscribe to:
Posts (Atom)