CN117348886A

CN117348886A - Method for realizing downward compatibility of native compilation on OpenEuler system

Info

Publication number: CN117348886A
Application number: CN202311372495.6A
Authority: CN
Inventors: 廖政高; 罗建; 吴文杰; 夏选琼; 何晓杰; 李琦; 尹道毅; 宋杨
Original assignee: Chongqing Cloud Core Intelligent Technology Co ltd; Chongqing Tsingshan Industrial Co Ltd
Current assignee: Chongqing Cloud Core Intelligent Technology Co ltd; Chongqing Tsingshan Industrial Co Ltd
Priority date: 2023-10-23
Filing date: 2023-10-23
Publication date: 2024-01-05

Abstract

The application relates to a method for realizing downward compatibility of native compiling on an OpenEuler system, which realizes the compatibility of a native program by adding another version of GLIBC, thereby solving the technical defect that a compatible program cannot be generated on a constructor in the prior scheme. By adopting the scheme, all applications needing native compiling can be compiled on an OpenEuler and run under other Linux systems with low-version GLIBC. When a user uses an operating system, the compiled compatible software on the Linux system can be directly used, normal application is not needed to be selected, the universality of the OpenEuler in Linux is not affected, meanwhile, a developer can easily develop and compile a native application program on the OpenEuler, and the program compatibility universality of the Linux system is improved.

Description

Method for realizing downward compatibility of native compilation on OpenEuler system

Technical Field

The disclosure relates to the technical field of Linux operating systems, and in particular relates to a method, a system and electronic equipment for realizing downward compatibility of native compilation on an OpenEuler system.

Background

OpenEuler, the proposed open source operating system, has a core similar to conventional CentOS Linux, employing rpm and dnf as packet management mechanisms.

The native application, especially refers to the application program directly running on CPU without considering the translation of the pseudo-machine, the application program has strong platform correlation and strong architecture correlation, can only run under the CPU with specific platform and specific architecture, and the execution performance of the program is very high and is 100-10000 times higher than that of the virtual machine or the interpreted program in return of the huge limitation of the running environment.

GLIBC, particularly a C/C++ runtime library under Linux, is integrated with a Linux operating system for running a C/C++ program under normal conditions, and the operating system itself can run normally only by relying on the GLIBC.

In the actual development process, there are various programs with strong performance requirements, and the native development (application) must be adopted, so the following problems occur:

because the GLIBC version of the OpenEuler is too high, the compiled program is developed under the OpenEuler, and the high-version GLIBC is dependent by default, once the program is put under other Linux, the GLIBC version of the system is lower than that of the OpenEuler, so that the problem that the program cannot run is caused.

The current solutions in the industry are: since the operating system also depends on the GLIBC, many key components are compiled by the GLIBC, the GLIBC carried by the OpenEuler cannot be degraded, and in the past development process, only the OpenEuler is involved as a development environment, so that the corresponding source code needs to be moved to another Linux carrying the old version of the GLIBC for compiling. However, the current solution has the disadvantage that it is necessary to have a Linux machine with its own old version of GLIBC, and to synchronize the code with the machine used for development for compilation (typically as a build machine). There are also problems that can be normally compiled and run on OpenEuler, but it is impossible to build on the build machine (the characteristics of new version of GLIBC are used in code) or it is not normally run (the difference in runtime conditions due to the difference in version of GLIBC).

The above problems have little solution under conventional solutions, and will affect all native programming languages, such as: C/C++/Go/Rust, etc., seriously affect the versatility of OpenEuler in Linux and make it impossible for developers to easily develop and compile native applications on OpenEuler.

Disclosure of Invention

In order to solve the above problems, the application provides a method, a system and an electronic device for realizing downward compatibility of native compilation on an OpenEuler system.

In one aspect of the present application, a method for implementing downward compatibility of native compilation on an OpenEuler system is provided, including the following steps:

selecting a first version GLIBC source code to be compiled;

compiling the first version GLIBC source code on an OpenEulter of the machine A to obtain a first version GLIBC; wherein, the OpenEuler of the machine A is provided with a third version GLIBC;

packaging and installing the first version GLIBC on an OpenEulter of the machine B;

and the OpenEulter of the machine B receives and decompresses the first version GLIBC, and places the decompressed first version GLIBC in a specified directory so that the first version GLIBC and a second version GLIBC on the OpenEulter of the machine B coexist.

As an alternative embodiment of the present application, optionally, the third version of GLIBC on OpenEuler of machine a is lower in version than the first version of GLIBC.

As an alternative embodiment of the present application, optionally, the second version of GLIBC on OpenEuler of machine B is higher in version than the first version of GLIBC.

As an optional embodiment of the present application, optionally selecting the first version of GLIBC source code to be compiled includes:

setting a compiling command;

designating a GLIBC version of the first version GLIBC source code to be compiled in the compiling command;

and downloading the corresponding first version GLIBC source code according to the GLIBC version, and participating in compiling of the first version GLIBC.

As an optional embodiment of the present application, optionally, compiling the first version of GLIBC source code on OpenEuler of machine a to obtain a first version of GLIBC includes:

acquiring the first version GLIBC source code;

generating information required by compiling through configuration commands, and configuring compiling options;

after the configuration is finished, compiling the configured compiling options by using a make command to obtain a compiling result: the first version of GLIBC.

As an optional embodiment of the present application, optionally, when performing the compiling option configuration, at least the following options are included:

options: saving the path;

options: whether default configuration information can be modified;

options: whether to treat the warning as an error.

As an optional embodiment of the present application, optionally, packaging and installing the first version of GLIBC on an OpenEuler of the machine B includes:

determining a designated directory to be installed on an OpenEuler of the machine B;

and compiling the result: the first version of GLIBC is packaged, and the compiled result is compiled using a make install command: the first version of GLIBC is installed to the specified directory.

As an optional embodiment of the present application, optionally, after the coexistence of the first version GLIBC and the second version GLIBC on the OpenEuler of the machine B, the method further includes:

acquiring the required quantity T of the first version GLIBC to be compiled by a user;

judging whether the required quantity T meets the following conditions:

T＞1，

if T is greater than 1, continuing compiling and packaging the GLIBC version corresponding to the required number T on an OpenEuler of the machine B according to the method of claim 1;

otherwise, giving up.

In another aspect of the present application, a system for implementing the method for implementing downward compatibility of native compilation on an OpenEuler system is provided, including:

the selection module is used for selecting a first version GLIBC source code to be compiled;

the compiling module is used for compiling the first version GLIBC source code on the OpenEuler of the machine A to obtain a first version GLIBC; wherein, the OpenEuler of the machine A is provided with a third version GLIBC;

the packaging and installing module is used for packaging and installing the first version GLIBC on an OpenEuler of the machine B;

and the decompression module is used for receiving and decompressing the first version GLIBC by the OpenEuler of the machine B, and placing the decompressed first version GLIBC in a specified directory so that the first version GLIBC and the second version GLIBC on the OpenEuler of the machine B coexist.

In another aspect of the present application, an electronic device is further provided, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the one method of implementing native compilation downward compatibility on an OpenEuler system when executing the executable instructions.

The invention has the technical effects that:

the method and the device realize the compatibility of the original program by adding another version of GLIBC, so that the technical defect that the compatible program cannot be generated on a building machine in the existing scheme is solved. By adopting the scheme, all applications requiring native compiling can be compiled on an OpenEuler by using the method, and any application developed by adopting C, C++, go, rust or other native programming languages can be run under other Linux systems with low-version GLIBC. When a user uses an operating system, the compiled compatible software on the Linux system can be directly used, normal application is not needed to be selected, the universality of the OpenEuler in Linux is not affected, meanwhile, a developer can easily develop and compile a native application program on the OpenEuler, and the program compatibility universality of the Linux system is improved.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments, features and aspects of the present disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 shows a schematic flow chart of an implementation of the present invention;

FIG. 2 shows a compilation schematic of a GLIBC2.31 compatible installation for the present invention;

FIG. 3 shows a logical schematic of compiling a GLIBC for the present invention;

fig. 4 shows a schematic application diagram of the electronic device of the invention.

Detailed Description

Various exemplary embodiments, features and aspects of the disclosure will be described in detail below with reference to the drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Although various aspects of the embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

In addition, numerous specific details are set forth in the following detailed description in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, well known means, elements, and circuits have not been described in detail so as not to obscure the present disclosure.

Example 1

As shown in fig. 1, in one aspect, a method for implementing downward compatibility of native compilation on an OpenEuler system is provided, including the following steps:

s1, selecting a first version GLIBC source code to be compiled;

s2, compiling the first version GLIBC source code on an OpenEuler of the machine A to obtain a first version GLIBC; wherein, the OpenEuler of the machine A is provided with a third version GLIBC;

s3, packaging the first version GLIBC and installing the first version GLIBC on an OpenEuler of the machine B;

s4, receiving and decompressing the first version GLIBC by the OpenEulter of the machine B, and placing the decompressed first version GLIBC in a specified directory to enable the first version GLIBC and a second version GLIBC on the OpenEulter of the machine B to coexist.

The invention mainly solves the problem that when the OpenEuler operating system is used, the program which is compiled under the system can not be normally used when being put into other Linux operating systems.

In the invention, a method of installing a set of independent old version GLIBC in OpenEuler and using the version for development and compiling is realized, and the method can allow the coexistence of multiple versions of GLIBC and specify the version of GLIBC to be relied on when compiling according to the requirement.

Before implementing the present embodiment, it should be clear that in the high-version GLIBC environment, the low-version GLIBC library cannot be directly compiled, so in the early stage of implementation, a Linux with the low-version GLIBC is necessary, and a higher-version GLIBC must be compiled using the low-version GLIBC as a dependency. And after the compiling result is obtained, packaging the compiling result and placing the compiling result in any position in an OpenEuler file system.

As shown in fig. 2, compatible software "GLIBC2.31" to be compiled will be taken as an example.

setting a compiling command;

For a program to be compiled, the problem to be solved here is how to select the specified GLIBC version, and therefore the specification needs to be made during the compilation process.

The compiling command is adopted, the GLIBC version is designated, and the designated GLIBC version is selected to participate in compiling.

Any compiling process, whenever GLIBC is used, may be assigned its version, the principle is a link command that the compiler is self-contained (in order not to distinguish between the compiler and the linker of part of the native language, the compiler is collectively referred to herein, and in order to illustrate that the two processes are integral).

It is noted that once it is decided to replace the version of GLIBC during compilation, a complete replacement must be made, not allowing only a part to be replaced (which would result in no linking) nor allowing multiple versions of GLIBC to be relied upon simultaneously (which would result in no compilation).

If the C/C++ language is adopted, the specific compiling command is as follows:

$gcc-L/opt/glibc-2.31/lib-linkmode"external"-extldflags"-static"。

if a language other than C/c++ is used, such as Go language, the GLIBC version may be specified in a similar manner:

$go build-ldflags'-s-w-L/opt/glibc-2.31-linkmode"external"-extldflags"-static。

The third version of GLIBC is the GLIBC2.28 on the OpenEuler of machine a in fig. 2.

The second version of GLIBC is the GLIBC2.36 that is self-contained on OpenEuler of machine B in fig. 2.

But in this embodiment the low version refers to 2.28 and the high version refers to 2.31. This is because, in the high-version GLIBC environment, the low-version GLIBC library cannot be directly compiled, so that in the early stage of implementation, a Linux with the low-version GLIBC itself is necessary, and a higher-version GLIBC must be compiled using the low-version GLIBC as a dependency. And after the compiling result is obtained, packaging the compiling result and placing the compiling result in any position in an OpenEuler file system.

Thus compiled on an OpenEuler and run under other Linux systems with their own low version GLIBC.

As shown in fig. 3, as an optional embodiment of the present application, optionally, compiling the first version of the GLIBC source code on the OpenEuler of the machine a to obtain a first version of the GLIBC includes:

acquiring the first version GLIBC source code;

After the compatible version GLIBC2.31 to be compiled is determined through the compiling command, source code configuration, compiling and packaging of the GLIBC2.31 are needed, and the first version GLIBC source code is compiled on an OpenEuler of the machine A to obtain the first version GLIBC.

First, machine a is self-contained 2.28.

Secondly, in order to compile the GLIBC2.31, the corresponding GLIBC2.31 source code needs to be searched and called from the GLIBC library.

And finally, compiling configuration and compiling packaging are carried out on the GLIBC2.31 source codes according to a preset compiling program.

In the actual compiling process, the GLIBC can select options and configure the options according to the user requirements.

At the time of compiling, different configurations need to be performed according to the GLIBC version to be compiled, the GLIBC version of the system, the operating system version, the dependency version of the operating system, and the like.

After the machine A compiles to obtain the first version GLIBC, the first version GLIBC is installed in a designated directory position on the OpenEuler of the machine B, so that when the final compiling is completed, a directory on which the compiling result is placed is obtained on the OpenEuler of the machine B.

The commands for implementing the compilation process on machine a and machine B described above are as follows:

machine a takes itself 2.28, compiles 2.31, and then puts the compiled result to machine B.

Machine B has no compilation process and simply takes the compiled result of machine a.

Coexistence refers to machine a alone 2.28, with compiled 2.31, and machine B alone 2.36, with machine a alone 2.31. The coexistence mode is that the GLIBC compiling result which needs to coexist is placed in a catalog which does not belong to the search range of the built-in library of the system.

options: saving the path;

options: whether default configuration information can be modified;

options: whether to treat the warning as an error.

When compiling the option configuration, the selection and configuration are needed according to the user requirement, but at least three options of saving path, whether default configuration information can be modified and whether warning is treated as error processing are needed to be compiled and configured.

The storage path is mainly used for designating a catalog, and the latter two configuration information is mainly used for determining the triggering condition of compiling alarm, so that compiling is convenient to monitor in real time in the compiling process, and a user is reminded of compiling requirements.

The specified directory is specified by the user, and can be specifically identified according to the read compiling command.

After the GLIBC2.31 compliant configuration is performed in the manner described above, the addition of other versions of the GLIBC application as desired on machine B may continue in the manner described above.

By adopting the scheme, the corresponding compiling log can be generated and stored in the background in each compiling process, and the compiling log is subjected to alarm examination through a compiling alarm rule preset in the background. And the method carries out alarm triggering judgment on the compiling logs on the machines A and B in a real-time online traversing way of compiling the logs, so that the software compiling versions which are not required by users can be conveniently screened out in time. And the coexisting GLIBC software can be sent to the user through the port to confirm whether the coexisting GLIBC software is consistent with the requirements.

In the same way, after the version is designated, compiling and executing are carried out.

judging whether the required quantity T meets the following conditions:

T＞1，

otherwise, giving up.

The above-mentioned software compiling that requires multiple GLIBC versions is specifically understood in conjunction with the above-mentioned steps, and will not be described herein.

After the GLIBC2.31 is compatible and installed, the user input program can be continuously read after the GLIBC2.36 in the machine B coexist, whether other GLIBC version compatibility requirements exist or not is judged, if so, the compiling program is continuously and automatically executed according to the mode, and the software application corresponding to the GLIBC version is compiled and installed.

At this time, the OpenEuler of the machine B becomes a system in which two GLIBC versions coexist, and a plurality of GLIBC versions can coexist according to the same method as described above.

Therefore, in the invention, a method of installing a set of independent old version GLIBC in an OpenEuler and using the version for development and compiling is realized, and the method can allow a plurality of versions of GLIBC to coexist and specify the version of GLIBC to be relied on when compiling according to the requirement.

When all applications requiring native compilation are developed by using C, C++, go, rust or other native programming languages, the method can be used to compile on an OpenEuler and run under other Linux systems with their own low-version GLIBC.

When the user uses the operating system, the "compiled compatible software" is used, so the user does not need to make a selection. For a developer, only the designated GLIBC version is selected to participate in compiling, so that the universality of the OpenEuler in Linux is not affected, and meanwhile, the developer can easily develop and compile a native application program on the OpenEuler, and the program compatibility universality of a Linux system is improved.

It should be noted that although the above is described as a GLIBC2.31 example, those skilled in the art will appreciate that the present disclosure should not be limited thereto. In fact, the user can flexibly set the requirements and the number of the GLIBC versions according to the actual application scene, so long as the technical functions of the application can be realized according to the technology.

It should be apparent to those skilled in the art that implementing all or part of the above-described embodiments may be accomplished by computer programs to instruct related hardware, and the programs may be stored in a computer readable storage medium, which when executed may include the processes of the embodiments of the controls described above. It will be appreciated by those skilled in the art that implementing all or part of the above-described embodiments may be accomplished by computer programs to instruct related hardware, and the programs may be stored in a computer readable storage medium, which when executed may include the processes of the embodiments of the controls described above. The storage medium may be a magnetic disk, an optical disc, a Read-only memory (ROM), a random access memory (RandomAccessMemory, RAM), a flash memory (flash memory), a hard disk (HDD), or a Solid State Drive (SSD); the storage medium may also comprise a combination of memories of the kind described above.

Example 2

Based on the implementation principle of embodiment 1, another aspect of the present application proposes a system for implementing the method for implementing native compilation downward compatibility on an OpenEuler system, which includes:

The function and interaction of the above-described individual modules is understood in conjunction with the principles of embodiment 1.

The modules or steps of the invention described above may be implemented in a general-purpose computing system, they may be centralized in a single computing system, or distributed across a network of computing systems, where they may alternatively be implemented in program code executable by a computing system, where they may be stored in a memory system and executed by a computing system, where they may be separately fabricated into individual integrated circuit modules, or where multiple modules or steps within them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

Example 3

As shown in fig. 4, in another aspect, the present application further proposes an electronic device, including:

a processor;

a memory for storing processor-executable instructions;

Embodiments of the present disclosure provide for an electronic device that includes a processor and a memory for storing processor-executable instructions. Wherein the processor is configured to implement any of the foregoing methods for implementing native compilation downward compatibility on an OpenEuler system when executing executable instructions.

Here, it should be noted that the number of processors may be one or more. Meanwhile, in the electronic device of the embodiment of the disclosure, an input system and an output system may be further included. The processor, the memory, the input system, and the output system may be connected by a bus, or may be connected by other means, which is not specifically limited herein.

The memory is a computer-readable storage medium that can be used to store software programs, computer-executable programs, and various modules, such as: a program or a module corresponding to a method for realizing downward compatibility of native compilation on an OpenEuler system is disclosed. The processor executes various functional applications and data processing of the electronic device by running software programs or modules stored in the memory.

The input system may be used to receive an input digital or signal. Wherein the signal may be a key signal generated in connection with user settings of the device/terminal/server and function control. The output system may include a display device such as a display screen.

The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for implementing native compilation downward compatibility on an OpenEuler system, comprising the steps of:

selecting a first version GLIBC source code to be compiled;

2. The method of claim 1, wherein the third version of GLIBC on OpenEuler of machine a is lower than the first version of GLIBC.

3. The method of claim 1, wherein the second version of GLIBC on OpenEuler of machine B is higher than the first version of GLIBC.

4. The method for implementing native compilation downward compatibility on an OpenEuler system according to claim 1, wherein selecting a first version of GLIBC source code to be compiled comprises:

setting a compiling command;

5. The method for implementing native compilation downward compatibility on an OpenEuler system according to claim 1, wherein compiling the first version of GLIBC source code on an OpenEuler of machine a to obtain the first version of GLIBC comprises:

acquiring the first version GLIBC source code;

6. The method for implementing native compilation downward compatibility on an OpenEuler system according to claim 5, wherein when the compilation option configuration is performed, at least the following options are included:

options: saving the path;

options: whether default configuration information can be modified;

options: whether to treat the warning as an error.

7. The method of claim 5, wherein packaging and installing the first version of GLIBC on an OpenEuler of machine B comprises:

8. The method for implementing native compilation downward compatibility on an OpenEuler system according to claim 1, wherein after enabling the first version GLIBC to coexist with the second version GLIBC on the OpenEuler of the machine B, further comprising:

judging whether the required quantity T meets the following conditions:

T＞1，

otherwise, giving up.

9. A system for implementing the method for implementing native compilation downward compatibility on an OpenEuler system according to any one of claims 1-8, comprising:

10. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any one of claims 1-8 when executing the executable instructions to implement native compilation downward compatibility on an OpenEuler system.