uClibc（轻量级C库）
参考网址：http://www.uclibc.org/
GNU的Glibc是一个非常宠大而完整的库，至少对于嵌入式系统来说，其体积显得过于大了一些。uClibc的提出较好的解决了这样一个问题。uClibc尽可能的兼容Glibc，大多数应用程序可以在很小或完全不修改的情况下就可能使用uClibc替代glibc。通过uClibc来代替Glibc，可以在不改变应用程序功能的前提下，大大减少发布文件的大小，无论应用程序以静态链接来编译，还是以动态链接形式编译。
不过使用uClibc代替并不是简单的设置一两个参数就行了，通常需要使用一个不同的工具集（gcc/binutils等）来编译源代码。手工的构造这样一个环境，对于大多数普通程序员来说，不一定是一件很简单的事情，因此，uClibc的开发者创造出一个叫做buildroot的工具集。buildroot将自动构造编译基于uClibc代码的工具集和uClibc库，并提供一个可配置的框架和一些构建一个基本系统的配置文件。用户只需要通过配置菜单选择了相应的目标软件，buildroot就可以从构建基本工具集开始，一直到最后构建出目标系统所需要的东西，如嵌入式系统常用的基于ext2的initrd，jffs根文件系统，压缩的根目录树等，这些代码都是基于uClibc而不是系统的Glibc的。
Buildroot对主机系统的要求较小，通常只需要主机系统提供足以构建工具链(toolchain)的工具，如gcc/binutils等，当工具链编译完成后，对目标系统需要的源码的编译过程与主机系统的开发工具集基本上就没有什么关系了。因此，不同的主机如果能够通过第一步，编译完成工具链，那么编译出来的目标系统的执行代码就可以几乎不存在由于系统引起的差异。这样，开发人员就可能在各自喜欢的Linux发行版上进行开发，而不必担心出现什么兼容性问题。
uClibc和Glibc也有许多不同之处:
http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt
相关文档：
整理自：http://forums.oracle.com/forums/thread.jspa?threadID=664180&tstart=0
问：Is it possible to use INNER JOIN's with Pro*C? I'm currently getting this error:
INNER JOIN t_diagnosis b ON a.sak_diag = b.sak_diag
....1
PCC-S-02201, Encountered the symbol "INNER" when expecting on ......
1：每一个变量在使用前都得声明，不然在使用的时候就有可能是随机的数字
2：注意头文件中函数声明的时候要在后面加上分号
3：注意串口可以打印变量，就像C中的printf一样
4：DNW中不能打印float型数据
5：注意结构体指针数组 的使用和调用
6： ......
作一个tcp的服务程序，同时可能有大量的客户端连上来，希望分别记住各个socket
谁有数据过来，就读出来，放到一个请求队列－－这些事情用一个线程完成
另外有一个结果队列，如果结果里包含了socket的编号，用一个线程专门：
取出来按编号找回原来发送者socket，发回给原来的客户端
还有一个就是处理� ......
首先、我们看32位的整数：int 、unsigned int、long、unsigned long 。这些都是基本类型，没有unsigned关键字的是有符号的，反之是无符号的。还有比如DWORD、 UINT这些也只是写别名（typedef）而已。有符号整数值得注意的是什么范围内是正数，什么范围是负数。这样对于加减运算、比较运算等有很大帮助，否则很容易溢出或者� ......
到最后还是自己解决了，导致该问题的原因是在linux启动到最后出现：
/bin/sh: can't access tty; job control turned off
而出现该错误的原因和解决方法google后有千百种，尝试了很多种都没有帮我解决问题。
下面是我自己的解决方法：
1. vi /etc/inittab 第一行添加
console::sysinit:/etc/init.d ......
