uClibc 和 Glibc 不一样

https://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt

uClibc 和 Glibc 不一样——有许多不同之处
可能会也可能不会给您带来问题。本文档试图列出这些
差异，完成后，将包含所有相关的完整列表
差异。


1) uClibc 比 glibc 小。我们试图保持与 glibc 兼容
接口，允许使用 glibc 编译的应用程序轻松编译
uClibc。但是，我们不包含 glibc 包含的_所有内容_，并且
因此某些应用程序可能无法编译。如果您遇到这种情况，请
向 uclibc 邮件列表报告失败，并附上详细的错误消息。

2) uClibc 比 glibc 更可配置。这意味着开发商
uClibc 的编译方式可能会导致大量
功能已被省略。

3) uClibc 甚至不尝试确保跨版本的二进制兼容性。
当新版本的 uClibc 发布时，您可能需要也可能不需要重新编译
你所有的二进制文件。

4) glibc 中的 malloc(0) 返回指向某物的有效指针（！？！？）
uClibc 调用 malloc(0) 返回 NULL。列出了 malloc(0) 的行为
由于 SuSv3 的实现定义，所以两个库同样正确。
这种差异也适用于 realloc(NULL, 0)。我个人觉得glibc的
行为不是特别安全。要启用 glibc 行为，必须
显式启用 MALLOC_GLIBC_COMPAT 选项。

4.1) glibc 的 malloc() 实现具有可通过
MALLOC_CHECK_ 环境变量。这主要用于提供额外的
malloc 调试功能。这些扩展的 malloc 调试功能不
在 uClibc 中可用。有很多不错的malloc调试库
可用于工作很多的 Linux（dmalloc、电栅栏、valgrind 等）
比 glibc 扩展 malloc 调试要好。所以我们省略了这个
uClibc 的功能并不是很大的损失。

5) uClibc 不提供数据库库（libdb）。

6) uClibc 不支持 NSS (/lib/libnss_*)，这使得 glibc 可以轻松
支持各种身份验证和DNS解析方法。仅限 uClibc
支持平面密码文件和影子密码文件进行存储
认证信息。如果你需要比这更复杂的东西，
你可以编译和安装pam。

7) uClibc 的 libresolv 只是一个存根。一些，但不是所有的功能
glibc 的 libresolv 提供的是 uClibc 内部提供的。其他功能
根本没有实施。

8) libnsl 为网络信息服务 (NIS) 提供支持
最初称为“黄页”或“YP”，是 RPC 发明的扩展
由 Sun 通过网络共享 Unix 密码文件。我个人认为NIS
是邪恶的可憎之物，不应使用。这些天，使用 ldap 很多
做同样事情的更有效的机制。uClibc 提供了一个存根
libnsl，但没有对网络信息服务 (NIS) 的实际支持。
因此，我们也不提供 glibc 提供的任何头文件
在 /usr/include/rpcsvc 下。

9) uClibc 的语言环境支持尚未 100% 完成。我们正在做这件事。

10) uClibc 的数学库只支持 long double 作为内联，甚至
那么多头双支撑是相当有限的。而且，极少数的
实现了浮点数学函数。坚持双倍，你应该
就好了。

11) uClibc 的 libcrypt 不支持可重入的 crypt_r、setkey_r 和
encrypt_r，因为 SuSv3 不需要这些。

12) uClibc 直接使用内核类型来定义大多数不透明的数据类型。

13) uClibc 直接使用 linux 内核的 arch 特定的 'stuct stat'。

14）uClibc的librt库目前缺少所有aio例程，所有时钟
    例程和所有 shm 例程（仅计时器例程和 mq
    例程被执行）。

<我们注意到的其他事情>



****************************** 曼努埃尔的笔记 ****************** ************

一些一般性评论...

我所有 uClibc 代码的预期目标是 ANSI/ISO C99 和 SUSv3
遵守。虽然存在一些 glibc 扩展，但许多最终会
可配置。此外，即使存在，类似 glibc 的扩展也可能
与本机 glibc 对应物略有不同或更严格。
它们主要是为了移植_aides_，不一定
即插即用的替代品。

现在了解一些细节...

时间函数
--------------
1) 不支持闰秒。
2) 不支持 /etc/timezone 和整个 zoneinfo 目录树。
   要设置时区，请按照中指定的设置 TZ 环境变量
   http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
   或者您也可以创建一个单行的 /etc/TZ 文件，以
   换行符，包含 TZ 设置。例如
   回声 CST6CDT > /etc/TZ
3) 目前，不支持特定于区域设置的时代和备用数字。
   它们在我的 TODO 清单上。

广泛的字符支持
-----------------
1) 目前唯一支持的多字节编码是 UTF-8。各种种类
   （可选）支持 ISO-8859-* 编码。内置的
   wchar 的表示假定为 31 位 unicode 值
   本机字节序表示。此外，底层的字符编码是
   假定匹配 0-0x7f 范围内的 ASCII。
2) 在语言环境支持的下一次迭代中，我计划添加对
   （至少一些）其他多字节编码。

语言环境支持
--------------
1) 支持的目标是 SUSv3 语言环境功能。而 nl_langinfo
   已扩展，类似于 glibc，它只返回相关的值
   语言环境条目。
2) 目前，应实现所有 SUSv3 libc 语言环境功能
   除了 wcsftime 和正则表达式中的整理项目支持。

标准输出
-----
1) printf 对大浮点值的转换有损失
   由于所使用的算法而导致的精度。
2) uClibc 的 printf 比 glibcs​​ 严格得多，尤其是在位置方面
   参数。首先解析整个格式字符串，如果出现则返回错误
   检测到问题。在 C 以外的语言环境中，检查格式字符串
   也是一个有效的多字节序列。此外，目前最多 10 个位置
   允许使用 args（尽管这是可配置的）。
3) BUFSIZ 是可配置的，但没有尝试自动调整内部
   stdio 流的缓冲区大小。事实上，stdio 代码一般牺牲
   最小尺寸的复杂性/性能。
4) uClibc 允许类似 glibc 的自定义 printf 函数。然而，虽然没有
   当前检查，说明符必须 <= 0x7f。
5) uClibc 允许类似 glibc 的自定义流。但是，没有缓冲区内搜索
   完毕。
6) 函数 fcloseall() 和 __fpending() 的行为可能与它们的不同
   glibc 对应。
7) uClibc 的 setvbuf 对于何时可以调用比 glibc 的更严格
   是。标准规定 setvbuf 必须在任何其他操作之前发生
   发生在溪流上。
8）现在，当格式使用位置时，printf 没有正确处理 %m
   参数。
9) glibc 的 fmemopen()、open_memstream() 和 fopencookie() 创建的文件
   无法进行广泛的定向。相应的uClibc例程做
   没有这个限制。
10) 对于 scanf，C99 标准规定“fscanf 函数返回
    如果在任何转换之前发生输入失败，则为宏 EOF。”但是 glibc 的
    scanf 不尊重分配被抑制的转换，即使
    尽管标准规定该值已转换但未存储。

Ulrich Drepper 拒绝承认或评论的 glibc 错误
  ( http://sources.redhat.com/ml/libc-alpha/2003-09/ )
-------------------------------------------------- ---------------------
1) C99 标准规定，对于 printf，%s 转换没有什么特别之处
   多字节字符的规定。SUSv3 就更清楚了，说明
   该字节被写入并且指定的精度以字节为单位。然而 glibc
   指定精度时将 arg 视为多字节字符串，并且
   不然。
2) C99 和 C89 都声明 scanf 的 %c 转换读取的是准确的
   由可选字段宽度指定的字节数（如果未指定，则为 1）。
   uClibc 符合标准。有一种说法可能是
   根据某些历史记录，指定的宽度应被视为上限
   采用。但是，应在一致性文档中提及此类行为。
3) glibc 的 scanf 在某些数字模式方面被破坏了。有些无效
   字符串被接受为有效（“0x.p”、“1e”、数字分组字符串）。
   尽管我发布的示例清楚地说明了这些错误，但它们仍然存在
   glibc 开发人员不承认。
4) glibc 的 scanf 似乎需要一个用于十六进制浮点字符串的“p”指数。
   根据标准，这是可选的。
5) C99 要求一旦遇到 EOF，就应该处理流
   就像在文件末尾一样，即使有更多数据可用。进一步阅读
   可以通过 clearerr() 或文件清除 EOF 标志来尝试
   定位功能。有关原始更改的详细信息，请参阅
   缺陷报告 #141。glibc 目前不合规，开发人员
   当我询问他们在这个问题上的官方立场时，没有发表评论。
6) glibc 的整理例程和/或 localedef 在隐式方面被破坏
   和明确的未定义规则。

更多的关注，因为我认为它......




分析：
-------------------------------------------------- -----------------

uClibc 不再支持 'gcc -fprofile-arcs -pg' 风格的分析，它
使您的应用程序生成一个“gmon.out”文件，然后可以对其进行分析
通过'gprof'。这不仅需要 uClibc 中明确的额外支持，它
要求您使用分析支持重建所有内容。两者都有
以这种方式分析应用程序的大小和性能损失，以及
就像海森堡效应一样，测量的行为改变了被测量的东西。

存在许多侵入性较小的替代方案，不需要您
专门检测您的应用程序，并重新编译和重新链接所有内容。

OProfile 系统范围的分析器是一个很好的替代方案：
      http://oprofile.sourceforge.net/

很多人使用 Valgrind 的组合取得了不错的效果
生成分析信息和 KCachegrind 进行分析：
      http://developer.kde.org/~sewardj/
      http://kcachegrind.sourceforge.net/

Prospect 是基于 OProfile 的另一种选择：
      http://prospect.sourceforge.net/

Linux Trace Toolkit (LTT) 也是一个很好的工具：
    http://www.opersys.com/LTT/

功能检查：
	http://www710.univ-lyon1.fr/~yperret/fnccheck/