Linker 为什么/lib/libc.so.1“；是否安装在solaris 10上？

为什么

/lib/libc.so.1

（

linker

/

loader

）总是安装在

solaris10

上？我尝试了

mount

和

df

输出。它显示了

/lib/libc.so.1

条目。

libc.so是运行用C编写的ssh或awk等unix命令并使用动态（运行时）链接所必需的。libc.so是指向libc.so.1的链接，libc.so.1是用于运行Solaris 10实现的C库的“基本”版本

Solaris的工作方式与Linux处理libc版本的方式不同，因为存在不同版本的sparc architecure。最低公分母是sparc 1。我有一个Ultrasparc III盒子和其他更现代的盒子

---

在libc.so.1上尝试file命令：

file/lib/libc.so.1

为了让实用程序和其他代码从框中获得最大值，libc的体系结构“sparc设置”与框匹配。阅读并尝试使用

isalist

和

isainfo

命令。

对于SPARC和x86体系结构，Solaris都提供了优化的C标准库。在引导时，最适合您的机器，即利用CPU特定指令和功能的机器，安装在标准机器的顶部

自Solaris 10以来，没有提供静态libc，因此此动态libc作为内核和用户之间的接口，是Solaris上运行的每个程序的必需组件

更多细节

有人可能会问，为什么要用lofs挂载而不是像符号链接这样的轻量级功能来实现这一点

原因是符号链接是持久的，即在重新启动后仍然存在。如果硬件功能不断发展，或者由于其他原因，错误的库可能链接到，使用符号链接可能会导致系统无法使用。同样，所有Solaris命令都动态链接到

libc.so

。很久以来，没有一个

libc.a

---

使用lofs挂载确保系统引导的第一阶段使用安全默认的

libc完成。因此

，并且只有在正确的时间选择了优化的一个，特别是允许在禁用所有服务的情况下（

-m milestone=none

）安全引导不会受到功能更改的影响。

您接受了一个答案，虽然陈述了正确的事实，但并没有直接回答IMHO您的“为什么安装libc”问题。链接文章解释了/lib/libc.so.1是动态的，系统如何选择使用哪一个以及安装的原因。但是，它和这个答案都不能解释为什么使用“mount”而不是使用符号链接或其他动态可用的方式。我的猜测是，使用mount提供了符号链接无法提供的功能。我不知道那会是什么，也许有些东西需要libc.so.1，但出于某种原因不会使用符号链接。@benrifkah有趣的一点。答案已更新。谢谢