glibc库详解及与POSIX,systemV这些库之间的关系说明
glibc glibc 是gnu发布的libc库，也即c运行库。
glibc是linux系统中最底层的api（应用程序开发接口），
几乎其它任何的运行库都会依赖于glibc。
glibc除了封装linux操作系统所提供的系统服务外，
它本身也提供了许多其它一些必要功能服务的实现，主要的如下：
（1）string，字符串处理
（2）signal，信号处理
（3）dlfcn，管理共享库的动态加载
（4）direct，文件目录操作
（5）elf，共享库的动态加载器，也即interpreter
（6）iconv，不同字符集的编码转换
（7）inet，socket接口的实现
（8）intl，国际化，也即gettext的实现
（9）io
（10）linuxthreads
（11）locale，本地化
（12）login，虚拟终端设备的管理，及系统的安全访问
（13）malloc，动态内存的分配与管理
（14）nis
（15）stdlib，其它基本功能
GLIBC 的内容
由于glibc 囊括了几乎所有的UNIX 通行的标准（比如system V和POSIX标准，glibc都是包括的），可以想见其内容包罗万有。而就像其他的UNIX 系统一样，其内含的档案群分散于系统的树状目录结构中，像一个支架一般撑起整个作业系统。以glibc-2.2 为例，这些档案群主要包括:
1.分享函式库群: （.so为共享函数库）
这是 glibc 的主体，分布 /lib 与 /usr/lib 中，包括 libc 标准 C 函式库、libm 数学函式库、libcrypt加密与编码函式库、libdb 资料库函式库、libpthread行程多执行绪函式库、libnss 网路服务函式库 .... 等等。这些都是可分享函式库，档名都以 .so 做结尾。其中，/lib/ld*.so 是程式与函式库连结的工具。有的用于程式编译时将程式与函式库内的函式物件连结，在只支援静态连结的系统中，此连结方式就是直接将所需的物件自函式库中抽出?砼c程式的可执行档相连，而在支援可分享函式库的系统中，在程式编译时期的连结只是在执行档中纪录了那些函式物件是存在那个函式库档案中，等该程式开始执行时，则由另一个负责动态连结的 ld*.so 将所需的函式库连结好?K执行。
一般而言，负责程式编译时期的连结器档名为 ld.so，而负责程式执行时的动态连结器档名为 ld- .so 或 ld-linux.so (在 GNU/Linux 系统中)。
函式库标头档与程式开发元件:
这些标头档档名都以 .h 为结尾，全部在/usr/include/ 底下，其内容为函式库中各函式的宣告、巨集定义、资料物件的型别 .... 等等，这些都是程式开发者不可或缺的部分。
除此之外，在 /usr/lib/ 中还有若干 .o 与 .a 的档案，这些是程式编译过程中要连结为可执行档时所需的元件，有些则为上述可分享函式库的静态连接版本，而后者可以在某些特殊场合下需要静态连结程式时使用。
函式库说明文件:
在一般的 UNIX 系统下，这些说明文件是放在/usr/man 或 /usr/share/man 底下，统称为 man pages，其底下还分若干章节，其中第二章 (man2) 讲的是系统呼叫，而第三章 (man3) 讲的就是 libc 标准函式库，这些都是系统开发者重要的参考资料。
而在 GNU 的系统中，除了 man pages 之外，还有一套称为 info 的文件资料系统，而且里头的说明往往比 man pages 还要详尽，这在 glibc 中也不例外。glibc 的info 文件位于 /usr/share/info/libc.info* ，本文中有许多素材就是取自这些文件的内容。
字集转换模组与区域化资料库:
这些是与程式国际化与本土化相关的部分，主要可分成四大块: /usr/lib/gconv/ 内含大量的字集转换模组，大部分是各种字集及编码方式与系统的基底字集之间的转换。第二块是 /usr/lib/locale，内含以系统基底字集写成的区域化资料库 (locale)，像是 LC_CTYPE、LC_TIME .... 等等。第三块是
/usr/share/locale/，内含可跨平台使用的区域化资料，主要是各应用程式的?息翻译部分。而最后一块是 /usr/share/i18n/，其内容是各区域化资料库的原始码，以及系统支援的内码对应表 .... 等等。
时区资料库:
主要分别在 /usr/share/zoneinfo 底下，内含世界各地时区与格林威治时间的转换资料。
其他工具程式与设定档:
工具程式分?言 /usr/bin 与 /sbin 底下，包括一些转码与区域化资料库相关的程式如 iconv, locale,localedef 等，以及用?盹@示应用程式与可分享函式库相依关系的 ldd, 还有可分享函式库搜寻路?焦芾沓淌 ldconfig .... 等。而其相关的设定档则位于 /etc 底下。
disaos
03-11-03, 10:42
GLIBC 的规格
在 GNU/Linux 系统中，其C函式库的发展史点出了 GNU/Linux 演进的几个重要里程碑，由此可以突显出 C 函式库在系统中的地位与重要性。早期的 GNU/Linux 系统?K不支援可分享函式库，因此所有的应用程式都是以静态连结的方式存于系统中。直到 1995-1996 年 libc5 问世以后，系统才开始支援 ELF 可分享函式库，同时该版的 C 函式库也?作了其他 UNIX 上大部分的功能与函式群，可谓 GNU/Linux 发展上的一大进步。
然而 libc5 在程式国际化 (I18N) 与本土化 (L10N) 方面的支援很差，故那个时候若要开发所谓中文化的程式，就非得自行?作一套标准不可。直到一两年后， GNU/Linux 换用了 GNU 所开发的 glibc-2.0 做为其 C 函式库后，其国际化与本土化的支援才开始起步，后?须v经 glibc-2.1，到了现在的 2.2 版，整个多国语文的开发环境才大至成熟。
用 glibc 做为系统的 C 函式库，是 GNU/Linux 演进的一个重要里程碑。在 GNU 的计画中，开发 glibc 原本是要给他们尚未问世的核心 GNU/Hurd 用的，由于当时几乎 99% 的 GNU 系统工具已开发完成，就独缺核心Hurd（内核kernel），而恰巧 Linux 核心在Torvalds 的带领下已逐?u成熟稳定，而且可以顺利执行所有的 GNU 系统工具。故 GNU 团队便顺应 Linux 核心的特性，改写了他们的 glibc，使其可以适用于 Hurd 核心与 Linux 核心。如此，在这两个平台上就有了一致的程式开发环境，使得所有的 GNU 程式可以在这两个平台之间顺利移植。
比起过去的libc5，glibc 系列(一般又称之为libc6) 除了有完整的国际化与本土化支援外，同时还符合许多标准与规格，使得在glibc 下开发的程式可以很容易移植到其他UNIX 平台去。这些标准包括:
(以下都是glibc支持的规范)
ISO C:
ISO C 是International Standardfor the C programming language 的缩写，此标准明定了C 语言的语法，标准C 函式库应具备那些标头档、巨集定义、函式与物件.... 等等，几乎在任何平台上的C 语言(包括非UNIX 平台) 都支援此标准。
POSIX:
POSIX 是Portable OperatingSystem Interface for Computer Environments 的缩写，它是ISO C的延伸，明定了一个可移植的作业系统所应具备种种条件，其范围不只有系统函式库而已，还同时包括一些标准的工具程式、系统核心应有的特色与?作、以及在C 函式库中某些与作业系统相关的低阶控制支援(如系统呼叫窗口) 等等。由于glibc 是完全按照POSIX 的标准制作的，同时搭配了符合POSIX 标准的Linux 核心，故在此环境下开发的程式可以做到完全符合POSIX 的规格。
Berkeley Unix:
Berkeley Unix 泛称柏克莱大学所开发的 UNIX 系列作业系统，包括 4.2 BSD、4.3 BSD、4.4BSD 以及早期的 SunOS。这些系统的 C 函式库中有许多杰出的设计，但却没有在上述两个标准中，包括 select() 函式、sockets .... 等等，这些在 glibc 中都有支援。
SVID:
SVID 是System V InterfaceDescription 的缩写，它是一份描述AT&T UNIX System V 系统规格的文件，它是POSIX 标准的延伸。Glibc ?作了大部分的SVID 规格要求，其中较重要的包括了行程之间的通?标准以及分享式记忆体(shared memory)，至于其他的部分则较不常使用。?作SVID 主要的目的是希望可以做到与UNIX System V 的相容与程式的可移植性。
XPG:
XPG 是 X/Open Portability Guide 的缩写，是由 X/Open Company, Ltd. 所发表，同时 X/Open 还拥有 UNIX 商标的版权。而这份规格不但是 POSIX 标准的扩充，同时也明定了一个 UNIX 作业系统所应符合的要求。其中包括了 iconv() 字集转换介面，以及部分 BSD 与 SVID 的特色。
glibc是linux系统中最底层的api（应用程序开发接口），
几乎其它任何的运行库都会依赖于glibc。
glibc除了封装linux操作系统所提供的系统服务外，
它本身也提供了许多其它一些必要功能服务的实现，主要的如下：
（1）string，字符串处理
（2）signal，信号处理
（3）dlfcn，管理共享库的动态加载
（4）direct，文件目录操作
（5）elf，共享库的动态加载器，也即interpreter
（6）iconv，不同字符集的编码转换
（7）inet，socket接口的实现
（8）intl，国际化，也即gettext的实现
（9）io
（10）linuxthreads
（11）locale，本地化
（12）login，虚拟终端设备的管理，及系统的安全访问
（13）malloc，动态内存的分配与管理
（14）nis
（15）stdlib，其它基本功能
GLIBC 的内容
由于glibc 囊括了几乎所有的UNIX 通行的标准（比如system V和POSIX标准，glibc都是包括的），可以想见其内容包罗万有。而就像其他的UNIX 系统一样，其内含的档案群分散于系统的树状目录结构中，像一个支架一般撑起整个作业系统。以glibc-2.2 为例，这些档案群主要包括:
1.分享函式库群: （.so为共享函数库）
这是 glibc 的主体，分布 /lib 与 /usr/lib 中，包括 libc 标准 C 函式库、libm 数学函式库、libcrypt加密与编码函式库、libdb 资料库函式库、libpthread行程多执行绪函式库、libnss 网路服务函式库 .... 等等。这些都是可分享函式库，档名都以 .so 做结尾。其中，/lib/ld*.so 是程式与函式库连结的工具。有的用于程式编译时将程式与函式库内的函式物件连结，在只支援静态连结的系统中，此连结方式就是直接将所需的物件自函式库中抽出?砼c程式的可执行档相连，而在支援可分享函式库的系统中，在程式编译时期的连结只是在执行档中纪录了那些函式物件是存在那个函式库档案中，等该程式开始执行时，则由另一个负责动态连结的 ld*.so 将所需的函式库连结好?K执行。
一般而言，负责程式编译时期的连结器档名为 ld.so，而负责程式执行时的动态连结器档名为 ld- .so 或 ld-linux.so (在 GNU/Linux 系统中)。
函式库标头档与程式开发元件:
这些标头档档名都以 .h 为结尾，全部在/usr/include/ 底下，其内容为函式库中各函式的宣告、巨集定义、资料物件的型别 .... 等等，这些都是程式开发者不可或缺的部分。
除此之外，在 /usr/lib/ 中还有若干 .o 与 .a 的档案，这些是程式编译过程中要连结为可执行档时所需的元件，有些则为上述可分享函式库的静态连接版本，而后者可以在某些特殊场合下需要静态连结程式时使用。
函式库说明文件:
在一般的 UNIX 系统下，这些说明文件是放在/usr/man 或 /usr/share/man 底下，统称为 man pages，其底下还分若干章节，其中第二章 (man2) 讲的是系统呼叫，而第三章 (man3) 讲的就是 libc 标准函式库，这些都是系统开发者重要的参考资料。
而在 GNU 的系统中，除了 man pages 之外，还有一套称为 info 的文件资料系统，而且里头的说明往往比 man pages 还要详尽，这在 glibc 中也不例外。glibc 的info 文件位于 /usr/share/info/libc.info* ，本文中有许多素材就是取自这些文件的内容。
字集转换模组与区域化资料库:
这些是与程式国际化与本土化相关的部分，主要可分成四大块: /usr/lib/gconv/ 内含大量的字集转换模组，大部分是各种字集及编码方式与系统的基底字集之间的转换。第二块是 /usr/lib/locale，内含以系统基底字集写成的区域化资料库 (locale)，像是 LC_CTYPE、LC_TIME .... 等等。第三块是
/usr/share/locale/，内含可跨平台使用的区域化资料，主要是各应用程式的?息翻译部分。而最后一块是 /usr/share/i18n/，其内容是各区域化资料库的原始码，以及系统支援的内码对应表 .... 等等。
时区资料库:
主要分别在 /usr/share/zoneinfo 底下，内含世界各地时区与格林威治时间的转换资料。
其他工具程式与设定档:
工具程式分?言 /usr/bin 与 /sbin 底下，包括一些转码与区域化资料库相关的程式如 iconv, locale,localedef 等，以及用?盹@示应用程式与可分享函式库相依关系的 ldd, 还有可分享函式库搜寻路?焦芾沓淌 ldconfig .... 等。而其相关的设定档则位于 /etc 底下。
disaos
03-11-03, 10:42
GLIBC 的规格
在 GNU/Linux 系统中，其C函式库的发展史点出了 GNU/Linux 演进的几个重要里程碑，由此可以突显出 C 函式库在系统中的地位与重要性。早期的 GNU/Linux 系统?K不支援可分享函式库，因此所有的应用程式都是以静态连结的方式存于系统中。直到 1995-1996 年 libc5 问世以后，系统才开始支援 ELF 可分享函式库，同时该版的 C 函式库也?作了其他 UNIX 上大部分的功能与函式群，可谓 GNU/Linux 发展上的一大进步。
然而 libc5 在程式国际化 (I18N) 与本土化 (L10N) 方面的支援很差，故那个时候若要开发所谓中文化的程式，就非得自行?作一套标准不可。直到一两年后， GNU/Linux 换用了 GNU 所开发的 glibc-2.0 做为其 C 函式库后，其国际化与本土化的支援才开始起步，后?须v经 glibc-2.1，到了现在的 2.2 版，整个多国语文的开发环境才大至成熟。
用 glibc 做为系统的 C 函式库，是 GNU/Linux 演进的一个重要里程碑。在 GNU 的计画中，开发 glibc 原本是要给他们尚未问世的核心 GNU/Hurd 用的，由于当时几乎 99% 的 GNU 系统工具已开发完成，就独缺核心Hurd（内核kernel），而恰巧 Linux 核心在Torvalds 的带领下已逐?u成熟稳定，而且可以顺利执行所有的 GNU 系统工具。故 GNU 团队便顺应 Linux 核心的特性，改写了他们的 glibc，使其可以适用于 Hurd 核心与 Linux 核心。如此，在这两个平台上就有了一致的程式开发环境，使得所有的 GNU 程式可以在这两个平台之间顺利移植。
比起过去的libc5，glibc 系列(一般又称之为libc6) 除了有完整的国际化与本土化支援外，同时还符合许多标准与规格，使得在glibc 下开发的程式可以很容易移植到其他UNIX 平台去。这些标准包括:
(以下都是glibc支持的规范)
ISO C:
ISO C 是International Standardfor the C programming language 的缩写，此标准明定了C 语言的语法，标准C 函式库应具备那些标头档、巨集定义、函式与物件.... 等等，几乎在任何平台上的C 语言(包括非UNIX 平台) 都支援此标准。
POSIX:
POSIX 是Portable OperatingSystem Interface for Computer Environments 的缩写，它是ISO C的延伸，明定了一个可移植的作业系统所应具备种种条件，其范围不只有系统函式库而已，还同时包括一些标准的工具程式、系统核心应有的特色与?作、以及在C 函式库中某些与作业系统相关的低阶控制支援(如系统呼叫窗口) 等等。由于glibc 是完全按照POSIX 的标准制作的，同时搭配了符合POSIX 标准的Linux 核心，故在此环境下开发的程式可以做到完全符合POSIX 的规格。
Berkeley Unix:
Berkeley Unix 泛称柏克莱大学所开发的 UNIX 系列作业系统，包括 4.2 BSD、4.3 BSD、4.4BSD 以及早期的 SunOS。这些系统的 C 函式库中有许多杰出的设计，但却没有在上述两个标准中，包括 select() 函式、sockets .... 等等，这些在 glibc 中都有支援。
SVID:
SVID 是System V InterfaceDescription 的缩写，它是一份描述AT&T UNIX System V 系统规格的文件，它是POSIX 标准的延伸。Glibc ?作了大部分的SVID 规格要求，其中较重要的包括了行程之间的通?标准以及分享式记忆体(shared memory)，至于其他的部分则较不常使用。?作SVID 主要的目的是希望可以做到与UNIX System V 的相容与程式的可移植性。
XPG:
XPG 是 X/Open Portability Guide 的缩写，是由 X/Open Company, Ltd. 所发表，同时 X/Open 还拥有 UNIX 商标的版权。而这份规格不但是 POSIX 标准的扩充，同时也明定了一个 UNIX 作业系统所应符合的要求。其中包括了 iconv() 字集转换介面，以及部分 BSD 与 SVID 的特色。