libc源码下载

⑴ c标准函数库源码下载

http://ftp.gnu.org/gnu/libc/ 应该是这个吧

⑵ centos6.5安装wps提示缺libc.so.6(GLIBC_2.15)(64bit),怎办

1.试图运行程序，提示"libc.so.6: version `GLIBC_2.14' not found",原因是系统的glibc版本太低，软件编译时使用了较高版本的glibc引起的：

[ghui@StuOS bin]$ pwd

/var/VMdisks/cross/mingw32/bin

[ghui@StuOS bin]$ ls

lrelease QtCore4.dll QtNetwork4.dll QtSql4.dll QtXml4.dll

moc QtDeclarative4.dll QtOpenGL4.dll QtSvg4.dll rcc

phonon4.dll QtGui4.dll QtScript4.dll QtTest4.dll uic

qmake QtMultimedia4.dll QtScriptTools4.dll QtWebKit4.dll

[ghui@StuOS bin]$ ./qmake

./qmake: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./qmake)

2.查看系统glibc支持的版本：

[ghui@StuOS bin]$ strings /lib64/libc.so.6 |grep GLIBC_

GLIBC_2.2.5

GLIBC_2.2.6

GLIBC_2.3

GLIBC_2.3.2

GLIBC_2.3.3

GLIBC_2.3.4

GLIBC_2.4

GLIBC_2.5

GLIBC_2.6

GLIBC_2.7

GLIBC_2.8

GLIBC_2.9

GLIBC_2.10

GLIBC_2.11

GLIBC_2.12

GLIBC_PRIVATE

[ghui@StuOS bin]$ rpm -qa |grep glibc

glibc-static-2.12-1.80.el6_3.6.x86_64

glibc-headers-2.12-1.80.el6_3.6.x86_64

glibc-common-2.12-1.80.el6_3.6.x86_64

glibc-devel-2.12-1.80.el6_3.6.x86_64

glibc-static-2.12-1.80.el6_3.6.i686

glibc-devel-2.12-1.80.el6_3.6.i686

glibc-2.12-1.80.el6_3.6.i686

glibc-2.12-1.80.el6_3.6.x86_64

3.可以看到最高只支持2.12版本，所以考虑编译解决这个问题：

a. 到http://www.gnu.org/software/libc/下载最新版本，我这里下载了glibc-2.14.tar.xz 这个版本，解压到任意目录准备编译

b.这里解压到/var/VMdisks/glibc-2.14/

[ghui@StuOS bin]$ cd /var/VMdisks/glibc-2.14/

[ghui@StuOS glibc-2.14]$ pwd

/var/VMdisks/glibc-2.14

[ghui@StuOS glibc-2.14]$ ls

abilist config.h.in intl README.libm

abi-tags config.log io resolv

aclocal.m4 config.make.in libc-abis resource

aout configure libidn rt

argp configure.in libio Rules

assert conform LICENSES scripts

autom4te.cache CONFORMANCE locale setjmp

bits COPYING localedata shadow

BUGS COPYING.LIB login shlib-versions

build cppflags-iterator.mk mach signal

CANCEL-FCT-WAIVE crypt Makeconfig socket

CANCEL-FILE-WAIVE csu Makefile soft-fp

catgets ctype Makefile.in stdio-common

ChangeLog debug Makerules stdlib

ChangeLog.1 dirent malloc streams

ChangeLog.10 dlfcn manual string

ChangeLog.11 elf math sunrpc

ChangeLog.12 extra-lib.mk misc sysdeps

ChangeLog.13 extra-moles.mk NAMESPACE sysvipc

ChangeLog.14 FAQ NEWS termios

ChangeLog.15 FAQ.in nis test-skeleton.c

ChangeLog.16 gmon NOTES time

ChangeLog.17 gnulib nptl timezone

ChangeLog.2 grp nptl_db tls.make.c

ChangeLog.3 gshadow nscd version.h

ChangeLog.4 hesiod nss Versions.def

ChangeLog.5 hurd o-iterator.mk wcsmbs

ChangeLog.6 iconv po wctype

ChangeLog.7 iconvdata posix WUR-REPORT

ChangeLog.8 include PROJECTS

ChangeLog.9 inet pwd

conf INSTALL README

c.在glibc源码目录建立构建目录，并cd进入构建目录

[ghui@StuOS glibc-2.14]$ mkdir build

[ghui@StuOS glibc-2.14]$ cd build

d.运行configure配置，make && sudo make install

[ghui@StuOS build]$ ../configure --prefix=/opt/glibc-2.14

[ghui@StuOS build]$ make -j4

[ghui@StuOS build]$ sudo make install

[sudo] password for ghui:

4.临时修改环境变量

[ghui@StuOS bin]$ export LD_LIBRARY_PATH=/opt/glibc-2.14/lib:$LD_LIBRARY_PATH

[ghui@StuOS glibc-2.14]$ cd /var/VMdisks/cross/mingw32/bin/

[ghui@StuOS bin]$ ./qmake

Usage: ./qmake [mode] [options] [files]

QMake has two modes, one mode for generating project files based on

some heuristics, and the other for generating makefiles. Normally you

shouldn't need to specify a mode, as makefile generation is the default

mode for qmake, but you may use this to test qmake on an existing project

...

⑶ 如何解决源码包安装时的依赖性问题

动态可执行文件使用最初编译和链接程序时使用的库文件的共享对象名称来查找共享对象。它们在少数的几个标准位置查找，比如在/lib和/usr/lib目录及在LD_LIBRARY_PATH环境变量（主要用于指定查找共享库，比如我们在安装Oracle时指定路径，exportLD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib）指定的目录中。顺便提一下，在这些库目录中找到的共享对象可能不是真正的文件;它们可能是指向位于其他位置的真实库文件的符号链接（但通常仍旧在标准库目录的一个目录中）。至少从系统管理员的观点是在用于创建共享库文件的共享库软件包的名称和共享库文件的名称之间通常没有什么关系。例如，GLIBC2.3软件包用于创建libc.so.6共享库文件。也从本示例中注意到，添加到共享库文件名结束的版本号(.6)跟用于创建它的版本号(2.3)没有关系。这是由共享库软件包开发人员有意完成的，以便GLIBC的新版本可以重用相同的共享库文件名libc.so.6。这允许您在系统上加载新版本的GLIBC，而不用中断动态链接到lib.so.6共享库文件的所有程序，当然假定新版本的GLIBC向后与动态可执行文件最初所链接的老版本GLIBC兼容。因此，即使库文件或共享对象文件有与它们相关的版本号，这些版本号也不能帮助你确定他们来自哪个版本的共享软件包。
注意：当将whatprovides选项用于rpm查询命令时，可以获得有关使用rpm软件包加载到系统的现有共享对象的信息。这种混乱是由下面的事实造成的：单个共享库文件可能支持某个范围的共享库软件包版本。例如，要检查soname库文件/lib/libc.so.6支持的GLIBC共享库软件包，运行下面的命令：
#objmp--all-headers/lib/libc.so.6|less
向下滚动此报告，直到到达Versiondefinitions:部分，以便查看libc.so.6共享库文件支持哪些GLIBC版本：
Versiondefinitions:
10x010x0865f4e6libc.so.6
20x000x0d696910GLIBC_2.0
30x000x0d696911GLIBC_2.1
GLIBC_2.0
40x000x09691f71GLIBC_2.1.1
GLIBC_2.1
50x000x09691f72GLIBC_2.1.2
GLIBC_2.1.1
60x000x09691f73GLIBC_2.1.3
GLIBC_2.1.2
70x000x0d696912GLIBC_2.2
GLIBC_2.1.3
80x000x09691a71GLIBC_2.2.1
GLIBC_2.2
90x000x09691a72GLIBC_2.2.2
GLIBC_2.2.1
100x000x09691a73GLIBC_2.2.3
GLIBC_2.2.2
110x000x09691a74GLIBC_2.2.4
GLIBC_2.2.3
120x000x09691a76GLIBC_2.2.6
GLIBC_2.2.4
130x000x0d696913GLIBC_2.3
GLIBC_2.2.6
140x000x09691972GLIBC_2.3.2
GLIBC_2.3
150x000x09691973GLIBC_2.3.3
GLIBC_2.3.2
160x000x09691974GLIBC_2.3.4
GLIBC_2.3.3
170x000x0d696914GLIBC_2.4
GLIBC_2.3.4
180x000x0d696915GLIBC_2.5
GLIBC_2.4
190x000x0963cf85GLIBC_PRIVATE
GLIBC_2.5
200x000x0b792650GCC_3.0
在本示例中，1ibc.so.6共享库文件支持原先为GLIBC版本2.0到2.5而开发的所有动态执行文件。注意：也可以使用objmp命令来从共享库文件中提取soname，命令如下所示：
#objmp--all-headers/lib/libcrypto.so.0.9.8b|grepSONAME
SONAMElibcrypto.so.6
objmp:/lib/libcrypto.so.0.9.8b:
接下来，将讨论rpm软件包是如何生成的，以便在新系统上安装rpm软件包时，这些共库依赖性是己知的。
三、Rpm软件包和共享库依赖性
当程序员生成rpm软件包时，ldd命令用于报告动态可执行文件软件包中所有动态可执行文件使用的所有共享库。另一个混乱是由下面的事实带来的：相同软件包中的不同动态可执行文件可能与相同的共享库软件包的不同版本进行链接。例如，Heartbeat软件包中的不同程序可能已经进行了开发，并动态链接到libc.so.6sonmae共享库文件的不同GLIBC版本。对rpm命令使用-q和--requires参数，可以看到rpm软件包需要的共享库的完整清单。例如，要看到Heartbeatrpm软件包所有的所需依赖性，请使用命令：
#rpm-q--requires-pheartbeat-1.x.x.i386.rpm
这产生了下面的报告：
sysklogd
/bin/sh
/bin/sh
/usr/bin/python
ld-linux.so.2
libapphb.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libccmclient.so.0
libdl.so.2
libglib-1.2.so.0
libhbclient.so.0
libpils.so.0
libplumb.so.0
libpthread.so.0
librt.so.1
libstonith.so.0
注意，在此报告中，libc.so.6soname是所需要的，此共享库必须支持使用GLIBC共享软件包版本号2.0、2.1、2.1.3、2.2和2.3进行链接的动态可执行文件。这是由下面的事实决定的：Heartbeat软件包中的不同动态可执行文件是针对不同版本的libc.so.6库的每个版本进行链接的。在了解了动态可执行文件、共享对象、soname和共享库软件包彼此是如何相关的后，下面准备来看这样的一个例子：当尝试安装rpm软件包，并且它由于依赖性错误而失败时，会发生什么。yum能够从指定的服务器自动下载RPM包并且安装，可以自动处理依赖性关系，并且一次安装所有依赖的软体包，无须繁琐地一次次下载、安装。
四、手工解决依赖性问题
通常，当尝试安装发行版中没有包括的软件包（及不能由像up2date、apt-get或Yum一样的更新工具自动解决其依赖性的软件包）时，将碰到rpm依赖性错误。例如，如果尝试在老的Linux发行版上使用rpm–ivh*rpm命令，例如所有的Heartbeatrpm包，那么在安装过程中就可能碰到下面的错误：
error:faileddependencies:
libc.so.6(GLIBC_2.3)isneededbyheartbeat-1.x.x
libc.so.6(GLIBC_2.3)isneededbyheartbeat-pils-1.x.x
libcrypto.so.0.9.6isneededbyheartbeat-stonith-1.x.x
libsnmp-0.4.2.6.soisneededbyheartbeat-stonith-1.x.x
注意，rpm命令没有干扰报告所需的每个GLIBC共享库软件包版本号——它只报告所需的最高编号的版本号(GLIBC_2.3)。(假定原来的软件包开发人员不会将相同软件包中的可执行文件链接到不兼容版本的共享库软件包)所有的这些故障都报告所需的共享库名称或soname（而不是文件名称，soname始终以“lib”开始）。但可以删除添加到rpm报告的soname结束的版本号，并快速检查以查看是否在系统中使用locate命令安装这些共享库(假设您的locate数据库是最新的，有关更多信息，请参阅locate或slocate的手册页)。例如，

⑷ c语言库函数源代码

http://www.gnu.org/software/libc/这里就有所有的c标准库函数源码。

⑸ fork()函数真正被实现的文件是哪个

fork 实际上是操作系统提供的系统调用 (syscall)，它是由操作系统，比如你在linux系统上，就要看内核源码。

至于程序中我们使用的 fork 接口本身，是由标准C库，libc 实现的，它其实很简单，直接调用了操作系统提供的系统调用。如果你是想看这个，去下载 glibc 源码找吧，不过没什么意义，对于系统调用来说，libc只是起个二传手的作用，自己什么都不做。

在linux内核源码中 linux-2.6.32.10/arch/x86/kernel/syscall_table_32.S 中是所有系统调用接口定义的地方。 搜索之后你会发现 sys_fork 最终调用了 do_fork

再在 linux-2.6.32.10/kernel/fork.c 可以看到 do_fork的实现。

所以具体的代码就在 kernel/fork.c 里了。

注意，你必须下载kernel源码才能找到上面提到的信息。

⑹ rar: /lib/libc.so.6: version `GLIBC_2.7′ not found (required by rar) 解决

在centos5.3下下载了个rar3.0
linux版本源码包，安装后执行rar命令发现提示rar:
/lib/libc.so.6:
version
`GLIBC_2.7′not
found
(required
by
rar)
打开压缩包是空的，所以此次在linux下安装rar并没有成功，根据错误信息应该是GLIBC_2.7′这个库的问题
查询了一番，找到的最简单的解决方案竟然是直接将源码包中的rar_static文件覆盖安装目录下的rar文件
根据makefile我们可以找到rar脚本的位置:/usr/local/bin
然后执行命令即可
from:http://www.wood-moon.org/index.php/rar-liblibc-so-6-version-glibc_2-7-not-found-required-by-rar

⑺ 如何看c语言标准库函数的源代码

1、首先标准只是规定了这些函数的接口和具体的运行效率的要求，这些函数具体是怎么写得要看各个编译器的实现和平台。

2、例如使用的编译器是visual studio，微软提供了一部分C运行时(CRT)的源码，里面会有memcpy，strcpy之类的函数的实现，在visual studio 2005下的路径是C:Program FilesMicrosoft Visual Studio 8VCcrtsrc。

⑻ 在linux下怎么查看每个函数的原型头文件都只是声明！man也只能查看用法！

glibc是linux下的libc库，你安装这个库之后，会将发布的头文件拷贝到 /usr/include下，而库文件被拷贝到/lib或者/usr/lib下，你在应用时，需要指定头文件路径以及库的路径；当然/usr/include和/lib、/usr/lib是系统的默认路径；
源码可以从glibc的官网下载到（http://www.gnu.org/software/libc/）

⑼ 在哪里可以找到C语言标准库的实现源代码

http://www.gnu.org/software/libc/
如果网页嫌麻烦，可以先装git，然后
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout --track -b glibc-2_11-branch origin/release/2.11/master

其实完全没有必要全都看，无论你有没有这个能力。因为由于历史兼容等问题，C标准库的代码并不是很适合学习，里面有些很杂乱。不过看过肯定比没看好，毕竟都是牛人写的。

望采纳，谢谢