Talk about the Linux application ABI compatibility

Talk about the Linux application ABI compatibility background

Recent work encountered a problem, that is, multiple systems running different versions of the kernel, different architectures of the arm chip, the upper level of the business process can be binary to one (total mirroring).

Based on your knowledge of Linux, GLIBC is able to do forward compatibility at the ABI level. Can the whole system do it? This reminds me of my analysis and thinking.

What does ABI compatibility depend on?

Imagine a program from the source code to the final binary, which components are involved in the compilation and linking process, presumably as follows:

• Kernel Export user-state header file
• The GCC compiler, the static. O/.a provided by GCC, and the dynamic libraries it provides (such as libgcc_s.so)
• glibc
• Third-party Open source libraries

It is necessary to analyze whether each group can achieve binary compatibility and how to do it. Below I will analyze the components to see if the ABI compatibility can be met with mind mapping.

The mind map above breaks down the components I think of, covering every detail. Of course, there will be some details that I have not thought of. The following are descriptions of less common components:

• Kernel Export Header file: Build cross-compiler tool chain is often done in the embedded, the tool chain construction needs to use the kernel exported the guide file. This is the basic type and data structure of the kernel state and the user contract, such as our common time_t,pid_t and so on type. The entire user-state software is based on it.
• GLIBC version mechanism: GLIBC to most symbols are version number, later in the later version of GLIBC, because of the POSIX/LSB standard changes, or the function interface has changed, it will create another version of the symbol, but the original version of the symbol still exists, while the semantics and parameters remain unchanged. It uses this mechanism to ensure the forward compatibility of the ABI (note that backward compatibility cannot be guaranteed)

From the perspective of analysis, most of the software can be kept forward compatible. This is why it is possible to copy the program from one mechanism to another, and the program will run normally.

Linux Standard Base (LSB)

Oh, is this a coincidence? Or what: all Linux programs run on all machines. I also take this problem to find some information.
Believe you heard about the POSIX specification, the Linux standard Base (LSB) specification. At first, I thought the LSB was an API specification, not an ABI specification. When I went deep into the analysis, I found that it was an ABI specification that solved two problems:

• Programs that run on the release Linux A can run on the release Linux B.
• The application runs on the current machine and can be run on new systems and machines in the future.

The recent launch of the LSB project by the Linux Foundation is to make it possible for Linux publishers to be compatible with each other and forward compatible. Solve the portability and compatibility of Linux applications.

The LSB is actually a set of ABI interface definitions that govern the binary interfaces of the types, macros, variables, and functions required by the runtime environment.

So, what are the things that are constrained by LSB? That is, the range of LSB specification constraints is much wider. At first, I thought that only kernel, glibc and other key components. In fact, opening the LSB website indicates that it is all-encompassing, from commands, ELF,GLIBC interfaces, to desktops, scripting languages, and so forth.

Who should abide by the LSB specification

There is no doubt that kernel, glibc, etc. should abide by the LSB standard. It's not the case. The LSB expects the Linux release (such as Redhat, Suse, Ubuntu) to follow the LSB, so it provides the LSB test suite and LSB authentication service.

Then kernel and glibc really do not need to consider the LSB, the answer is negative. The entire KERNEL/GLIBC and major Linux well-known components are developed in open source, the technology is already not a secret, the major companies have engineers involved, all companies hope that the software is to comply with the LSB, so that all the software can easily blend together, Do not want to let the occurrence of peddler spend a great effort to integrate. As a result, all software will try to comply with the LSB specification, but cannot exclude cases with one or two exceptions.

GLIBC is the most used components, but also I know one of the components, to the Internet to find some of its compatibility analysis, found that it can not guarantee 100% forward compatibility. Not fully compatible occurs on 2.16.0 and 2.13 of two versions. This compatibility is fully sufficient for general software at the moment.

"Backwards" compatibility

So can Linux be backwards compatible? The answer is no, because the LSB is not backwards compatible.

That's the problem, if I need to do backwards compatibility? If you have the following scenario:

Many servers are Ubuntu 7.04, which is a server 8 years ago, a lot of. At the same time, there will be a server using 12.04, a small number. However, the compiler on 12.04 is newer and supports many security features. The architect's claim is: can build based on the 12.04 version of the environment, the generated service program can run on both 7.04 and 12.04 two servers.

The solution I can think of:

• Find Ubuntu 7.04 and 12.04 servers running software, followed by the LSB version, the service program can only call these two LSB fully compatible interface
• When programming and linking a service program, you can specify the LSB standard that the program uses (Ubuntu 7.04 version of LSB).

For the first method, the individual considers it feasible, but has many constraints. Method two unknown feasible, subsequent re-analysis

This is one of the issues that "backwards" compatibility would like to discuss. It is not true backwards compatibility and is completely dependent on forward compatibility.

Postscript

Compatibility, is not the things I am familiar with, but the work encountered problems, did a preliminary analysis. I hope that through the blog record my thinking, when one day, I have in-depth experience of this knowledge, and then share with you. If there is inaccurate, or misleading content, please correct me, thank you!

2015/7/11 in Shanghai can Hong Typhoon hit

Copyright NOTICE: This article is the original article of Bo Master, please indicate the author and source by the courtesy reprint

Talk about the Linux application ABI compatibility