linux file 命令输出中的版本号字段是什么
如果我对在 Fedora Core 11 上编译的名为“version”的可执行文件执行以下命令,我会得到以下输出
文件
版本:ELF 32-bit LSBexecutable, Intel 80386, version 1 (SYSV),dynamic linked (uses share libs) ),对于 GNU/Linux 2.6.18,未剥离
末尾的 2.6.18 数字有何意义,对于区分客户的版本有什么用处他们应该下载一些软件?
从我到目前为止所看到的来看,这个数字绝对不是
- 内核版本
- libc 版本
- 与 lsb_release 有关的任何东西
我想获得一些简单的标识符,以允许客户知道他们应该下载哪个二进制版本,他们应该下载哪个版本理想情况下应该能够通过键入命令来识别(例如 uname -a,尽管这显然不是本例中的命令)。
谢谢
If I do the following command on my executable called "version", compiled on Fedora Core 11, I get this output
file version
version: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
What's the significance of the 2.6.18 number towards the end, and is it any use in distinguishing to customers which version of some software they should download ?
From what I've looked at so far, this number is definitely not
- The kernel version
- The libc version
- Anything to do with the lsb_release
I'd like to get some easy identifier to allow customers to know which binary release they should download, which they should ideally be able to identify by typing a command (like uname -a, although that obviously isn't the one in this case).
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
它是编译二进制文件的机器的内核版本。如果您使用发行版中的预编译二进制文件,则它是发行版供应商的机器的内核版本,可能位于其编译场中。
例如,在考虑系统调用时,它是相关的。假设您的二进制文件使用系统调用号。
X
并且您使用的内核尚不支持X
或更糟的是分配了系统调用号。X
到不同的系统调用。普通的 Linux 内核用户 API 是稳定的。这意味着如果
A <=B
,Linux 版本A
中可用的每个系统调用也可以在 Linux 版本B
中使用。但某些开发人员可能会发布他/她自己的 Linux 开发版本(例如linux-2.6.18-xy
),并且他/她实现了一个新的系统调用。如果他/她现在使用该内核版本编译二进制文件,则该二进制文件将被标记为该版本。因此,您稍后可以知道它可能有效也可能无效。顺便说一句,
/usr/include/asm/unistd_32.h
包含系统调用号,摘录:It's the kernel version of the machine the binary was compiled on. If you use precompiled binaries from your distribution, it's the kernel version of a machine of the distribution vendor, probably in its compile farm.
It's relevant e.g. when considering syscalls. Say your binary uses the syscall no.
X
and you use a kernel which does not supportX
yet or worse has assigned syscall no.X
to a different syscall.The vanilla Linux Kernel User API is stable. That means every syscall available in Linux version
A
is available in Linux versionB
ifA <=B
. But it may happen that some developer releases his/her own development version of Linux (something likelinux-2.6.18-xy
) and s/he implements a new syscall. If s/he now compiles a binary using that kernel version, the binary gets tagged with that version. So, you are later on able to know that it may or may not work.Btw,
/usr/include/asm/unistd_32.h
contains syscall numbers, excerpt:“file”命令输出中显示的内核版本取自名为“.note.ABI-tag”的 ELF(Linux 上常见的可执行文件格式)部分。它不是由内核定义的,而是由编译程序的 GNU libc 定义的。
这里的数字定义了 C 库至少期望的 Linux 内核 API 级别(支持的系统调用),并在 crt1.o 的 .note.ABI-tag 部分中定义,启动对象静态链接到每个可执行文件。有关详细信息,请参阅其规范。
虽然 Johannes Weiss 普遍认为 API 是稳定的(并且向后兼容)是正确的,但提供新功能的新接口会定期实现。最新的主要 API(截至 2024 年)将是用于 32 位系统(例如 ARM 32)的 64 位时间 API,在 Linux 内核 5.15.0 中引入,并与 GNU libc 2.34 及更高版本一起使用,我们将需要它。 2038 年达到 UNIX 时间的 2^31 秒。
The kernel version shown in the "file" command output is taken from an ELF (the common executable file format on Linux) section called ".note.ABI-tag". It is defined not by the kernel, but the GNU libc the program is compiled on.
The number here defines the Linux kernel API level (the supported syscalls) the C library expects at a minimum and is defined in the .note.ABI-tag section in crt1.o, the startup object statically linked into every executable. For details, see its specification.
While Johannes Weiss is generally right that API is stable (and backward compatible), new interfaces that deliver new features are regularly implemented. The newest major one (as of 2024) would be the 64-bit time API for 32-bit systems (e.g. ARM 32), introduced in Linux kernel 5.15.0 and utilised with GNU libc 2.34 and newer, which will be needed after we hit 2^31 seconds of UNIX time in 2038.