一般来说，如果库的头文件不在 /usr/include 目录中，那么在编译的时候需要用 -I 参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也可以将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用 -I 参数指定的头文件的路径也可能不同，其结果就是造成了编译命令界面的不统一。如果使用 -L 参数，也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。
为了解决编译和连接界面不统一的问题，人们找到了一些解决办法。其基本思想就是：事先把库的位置信息等保存起来，需要的时候再通过特定的工具将其中有用的 信息提取出来供编译和连接使用。这样，就可以做到编译和连接界面的一致性。其中，目前最为常用的库信息提取工具就是下面介绍的 pkg-config...
一个朋友问了一个js问题, 一段看不出有任何问题的代码, 在ie下报错:"object doesn't support this property or method".
function foo(obj) {
productTree = obj.toString();
document.getElementById('productTree').innerHTML = productTree;
}
Filed in Js/CSS
with 13 Comments
通过在nginx.conf中模拟PATH_INFO的方法会有一个bug. 那就是PATH_INFO不会被urldecode.
对于Apache+PHP(php2handler)来说, PATH_INFO来自Apache, 不会有问题, 对于Apache fastcgi也应该没有问题, 因为PATH_INFO也是由Apache生成.
但是对于nginx+fastcgi, 因为对于cgi来说PATH_INFO来自于ENV(fastcgi_params), 而php-cgi中的import_environment_variables不会对ENV中的变量做urldecode.
这样, nginx看到的url是urlencode以后的, 从url中分离出来的PATH_INFO也是urlencode后的, forward给php proxy以后, PHP看到的PATH_INFO也是urlencode的了.
所以, 如果在PATH_INFO中包含一些宽字符, 或者是"+", 那就要注意了, 需要我们主动的urldecode一下再使用.
Filed in PHP应用
with 14 Comments
一个想当然造成的错误.
需求是这样的, 我需要给一个二进制流加入一个签名串. 那么首先, 理所当然我的写了一个签名函数, 考虑到要判断签名操作是否成功, 所以我采用了传引用:
function sign(&$carrier, $fingerprint) {
if (NULL === $fingerprint) {
return FALSE;
}
//加入签名
$carrier = 签名逻辑.
return TRUE;
}
接下来, 考虑到, 如果签名失败, 那还是使用原来的字符串做为结果, 所以, 我想当然的写下了如下的代码....
with 14 Comments2009年就这么过去了, 刚吃了个饭, 和朋友打了会儿球, 回来就2010年了.
呵呵, 祝福大家2010年, 事事顺利, 天天开心.
Rss feed改成全文输出了, 这样订阅我blog的朋友看的就会更方便了. (大家可能需要刷新下reader, 这样之前的文章就可以全文浏览了).
另外, 想着该给blog换个皮肤了. 新年新气象么, 🙂
Filed in 随笔
with 6 Comments