在Linux环境下调试静态库
这两天同事在Octeon开发板上调试Linux程序，遇到了一个问题：无法让gdb单步跟踪进入静态库（libcrypto.a和libcvmx.a）对应的源文件。
我自己在PC上写了一个小程序进行验证，发现果然是这样。如果把全部.o文件（用-ggdb3选项编译，带调试信息）直接编译成可执行文件，是可以跟踪进入.o文件对应的源文件的；如果先把其中几个.o文件用ar命令打包成静态库，再和主程序的.o文件一起编译成可执行文件，gdb就跟踪不进去了。
观察了一下.a文件和.o文件的大小，我发现.a文件的体积远远小于全部.o文件的总和，看来是在打包的过程中把调试信息弄丢了。上网查了一下，发现只要使用-s（小写s，不是大写S）选项，就可以在.a文件中保留符号信息。
于是先修改$OCTEON_ROOT/components/crypto-api/core/crypto.mk文件的第22行，将“CFLAGS_CRYPTO += -O2”改为“CFLAGS_CRYPTO += -ggdb3”，再修改$OCTEON_ROOT/components/crypto-api/core/crypto/crypto.mk文件的第146行，将“$(AR) -r $@ $^”改为“$(AR) -rs $@ $^”，接着进入$OCTEON_ROOT/components/crypto-api/core/test-api目录进行编译，就可以得到新的libcrypto.a（体积比原先膨胀了几十倍，超过了100M），最后在Eclipse中添加源文件搜索路径（$OCTEON_ROOT/components/crypto-api/core，包含子目录），gdb就能正确跟踪进入libcrypto.a对应的源文件了。
对于libcvmx.a应该也可以进行类似的处理，不过估计体积会超过300M了，有兴趣的读者可以尝试一下。
相关文档：
我们知道，在linux下，我们用errno来查看API返回的错误码，并用strerror(errno)来获得错误信息。
而在windows下也有这的错误码，可以用GetLastError
来获得，在windows下，要获得错误码对应的信息就没有linux下那么方便了。
其获得方式可以参考《windows核心编程》。
但我们也可以用linux下的api来获得windows下的错误� ......
linux 2.6内核进程管理
linux每个进程对应一个task_struct类型结构。该结构包含进程相关的所有信息。linux进程通过list_head组织双向链表，每一个结点就是一个进程描述符。进程描述符里面包含了进程所有的信息：进程所打开的文件、进程的地址空间、挂起信号、进程状态和其他更多的信息。以下是进程描述� ......
转自：http://blog.itpub.net/post/33256/413374/
怎么样在红帽企业Linux2.1上配置VNC?
怎样配置VNC服务器使其能在红帽企业Linux3系统引导时自动启动?
怎
么样在红帽企业Linux2.1上配置VNC?
解决方法:1. 首先，我们需要查看是否已经安装了需要的VNC包。作为根用户，运行这个命令：
rpm
-qa | grep vnc
如果RPM� ......
