如何/usr/lib64/libc.所以生成的?

[root@xx test]# cat /usr/lib64/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )

Anyone knows how this kind of stuff is generated?

有人知道这种东西是怎么产生的吗?

2 个解决方案

#1

This is generated when glibc is compiled using Make utility.

这是在使用Make工具编译glibc时生成的。

There is a rule (started by make install) in glibc's Makefile, which does just echo needed lines into some temporary file $@.new:

在glibc的Makefile中有一个规则(由make install开始)，它只是将需要的行echo到一些临时文件$@.new:

(echo '/* GNU ld script';\
 echo '   Use the shared library, but some functions are only in';\
 echo '   the static library, so try that secondarily.  */';\
 cat $<; \
 echo 'GROUP ( $(slibdir)/libc.so$(libc.so-version)' \
      '$(libdir)/$(patsubst %,$(libtype.oS),$(libprefix)$(libc-name))'\
      ' AS_NEEDED (' $(slibdir)/$(rtld-installed-name) ') )' \
) > $@.new

And then this file is renamed to libc.so

然后这个文件被重命名为libc。

mv -f $@.new $@

Here is a comment from Makefile, which explains a bit:

这里是Makefile的一个注释，它解释了一点:

# What we install as libc.so for programs to link against is in fact a
# link script.  It contains references for the various libraries we need.
# The libc.so object is not complete since some functions are only defined
# in libc_nonshared.a.
# We need to use absolute paths since otherwise local copies (if they exist)
# of the files are taken by the linker.

I understand this as: libc.so.6 is not complete and needs something, which can't be stored in shared library. So, glibc developers moved this something to static part of glibc - libc_nonshared.a. To force always linking both libc.so.6 and libc_nonstared.a, they created a special linking script which instructs ld linker to use both when it is asked for -lc (libc)

我理解这是:libc.so。6是不完整的，需要一些东西，不能存储在共享库中。因此，glibc开发人员将此操作转移到glibc - libc_nonshar. a的静态部分。总是把libc和libc连接起来。6和libc_nonstared。a，他们创建了一个特殊的链接脚本，它指示ld链接器在请求-lc (libc)时使用它们。

What is in the nonshared part? Let's check:

什么是非共享部分?让我们检查:

$ objdump -t /usr/lib/libc_nonshared.a |grep " F "|grep -v __
00000000 g     F .text  00000058 .hidden atexit
00000000  w    F .text  00000050 .hidden stat
00000000  w    F .text  00000050 .hidden fstat
00000000  w    F .text  00000050 .hidden lstat
00000000 g     F .text  00000050 .hidden stat64
00000000 g     F .text  00000050 .hidden fstat64
00000000 g     F .text  00000050 .hidden lstat64
00000000 g     F .text  00000050 .hidden fstatat
00000000 g     F .text  00000050 .hidden fstatat64
00000000  w    F .text  00000058 .hidden mknod
00000000 g     F .text  00000050 .hidden mknodat
00000000 l     F .text  00000001 nop

There are atexit(), *stat*(), mknod functions. Why? Don't know really, but it is a fact of glibc.

有atexit()、*stat*()、mknod函数。为什么?不知道，但这是glibc的一个事实。

Here is some long explaination http://giraffe-data.com/~bryanh/giraffehome/d/note/proglib and I cite beginning of it:

以下是一些长期的解释:http://长颈鹿-data.com/~bryanh/长颈鹿家庭/d/note/proglib:

The stat() family of functions and mknod() are special.  Their
interfaces are tied so tightly to the underlying operating system that
they change occasionally.

#2

-1

On managed systems you may need to install glibc-devel and/or glibc-devel.i686.

在托管系统上，您可能需要安装glibc-devel和/或glibc-devel.i686。

#1