Method and system for automatically generating intelligent adaptation layer based on API (Application Program Interface) change

Abstract

The invention discloses an automatic generation method and system for an intelligent adaptation layer based on API change. The method comprises the steps that API change detection is conducted according to new and old version API interface definitions, adaptation codes are generated according to an API change detection result and compiled into a compatible adaptation layer library, and the compatible adaptation layer library is packaged into an installation package; in the installation stage, the new version target library and the compatible adaptation layer library are installed in a target directory; and loading the compatible adaptation layer library prior to the new-version target library in the running stage, taking over and processing the old-version API interface through the compatible adaptation layer library, and transferring the new-version API interface in the new-version target library. The invention aims to solve the compatibility problem caused by the API change of the software library, realize the automatic generation of the intelligent adaptation layer to ensure the seamless compatibility of the application program with different version libraries under the RPM and other software package management systems, and reduce the maintenance workload for solving the incompatibility problem caused by the API change.

Description

Technical Field

[0001] The present invention relates to the technology of maintaining and automatically adapting the Application Binary Interface (ABI) compatibility in the Linux RPM software package ecosystem in the field of software engineering, and specifically relates to a method and system for automatically generating an intelligent adaptation layer based on API changes. Background Art

[0002] With the iterative update of software, the Application Programming Interfaces (APIs) of underlying libraries often change. In the Linux distribution ecosystem using RPM package management (such as RHEL, CentOS, Rocky Linux, openEuler, etc.), the upgrade of system components and libraries may introduce the addition, deletion, or parameter modification of APIs. Such API changes often cause applications compiled based on the old version libraries to fail to run properly in the new environment. For example, if the parameter list of a function called by an application changes or is removed in the new version library, a linking error or functional abnormality will occur during runtime if not processed.

[0003] Traditionally, there are mainly the following methods to solve the incompatibility problems caused by API changes: First, manually modify the application code to adapt to the new API, and then recompile to generate a new version of the software package; Second, keep the old version of the library in the system (such as providing a compatibility package) to meet the dependencies of the old applications; Third, write an adaptation layer (shim layer) for the old and new APIs to convert the old interface calls into new interface calls at runtime. These methods all have obvious limitations: 1. Manual adaptation and recompilation: It requires developers to spend a lot of time understanding the differences between the old and new APIs and modifying the code. It is even more powerless for applications without source code (only binary packages are provided). Even with source code, the frequent manual adjustment and re - building process is prone to introducing new errors and has high maintenance costs. 2. Co - existing old library versions: Installing multiple versions of the library in the system will increase the maintenance complexity, occupy extra space, and may cause dependency chaos. Moreover, not all distributions are willing to provide long - term support for the old versions of the library, which burdens the system security and maintenance. 3. Manually writing the adaptation layer: Developers need to write wrapper code for each changing API to convert the old interface calls into new interface calls. This manual method is time - consuming and laborious, and prone to errors. If the adaptation layer code is not properly maintained, new bugs or performance overhead may occur. As the API changes accumulate, the amount of manually adapted code will also rapidly expand. Some existing API compatibility checking tools (such as ABI Compliance Checker, libabigail, etc.) can compare the version differences of libraries and report incompatible interface changes. However, such tools usually only focus on detecting and reporting differences and do not provide the function of automatically generating adaptation code. Therefore, developers still need to manually write a large amount of adaptation code based on the difference reports. In a large - scale software ecosystem, this manual intervention not only has high costs and high error rates, but also it is difficult to ensure that all changes are correctly processed. This highlights the deficiencies of the existing technologies, and there is an urgent need for a mechanism that can automatically detect API changes and generate the corresponding adaptation layer code to reduce the maintenance workload. Summary of the Invention

[0004] The technical problem to be solved by the present invention: Aiming at the above problems of the existing technology, the present invention provides a method and system for automatically generating an intelligent adaptation layer based on API changes. The present invention aims to solve the compatibility problems caused by software library API changes, realize the automatic generation of an intelligent adaptation layer to ensure the seamless compatibility of application programs with different versions of libraries under software package management systems such as RPM, and reduce the maintenance workload of solving the incompatibility problems caused by API changes.

[0005] To solve the above - mentioned technical problems, the technical solution adopted by the present invention is as follows: An intelligent adaptation layer automatic generation method based on API changes, comprising the following steps: S1. During the packaging stage of the application, obtain the old version API interface definition and the new version API interface definition of the software package; Perform API change detection based on the old version API interface definition and the new version API interface definition; Generate adaptation code according to the API change detection result; Compile the source code of the application into a new version target library, compile the adaptation code to generate a compatible adaptation layer library, and package the new version target library and the compatible adaptation layer library into an installation package; S2. During the installation stage of the application, install the new version target library and the compatible adaptation layer library into the target directory; S3. During the running stage of the application, load the compatible adaptation layer library prior to the new version target library, take over the processing of the old version API interface through the compatible adaptation layer library, and transfer and call the new version API interface in the new version target library to achieve the compatible adaptation of the application API change.

[0006] Optionally, in step S1, performing API change detection based on the old version API interface definition and the new version API interface definition includes: Generate an abstract syntax tree of the old version API interface definition using a compilation front-end tool; Generate an abstract syntax tree of the new version API interface definition using a compilation front-end tool; Perform abstract syntax tree difference detection on the abstract syntax tree of the old version API interface definition and the abstract syntax tree of the new version API interface definition to obtain an abstract syntax tree difference detection result; Compare the binary interfaces of the old version API interface definition and the new version API interface definition using an ABI difference analysis tool to obtain an ABI difference analysis result; Combine the abstract syntax tree difference detection result and the ABI difference analysis result to generate an API change list, and each entry in the API change list corresponds to an API change.

[0007] Optionally, the information recorded in each entry of the API change list includes the name of the API interface involved, the API change description, and the change type, and the change type includes some or all of function parameter change, function symbol change, and function return value change.

[0008] Optionally, in step S1, generating the adaptation code according to the API change detection result includes traversing each entry in the API change list, and selecting the corresponding code snippet from the predefined adaptation code template library according to the change type of the entry to generate the corresponding adaptation code, including: if the change type is function parameter change, generating a wrapper function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function parameters of the wrapper function being the same as the function parameters of the old version API interface, and internally calling the new version API interface after adapting the function parameters, and the parameter adaptation including part or all of assigning default values, type conversion, and format adjustment to the function parameters between the old version API interface and the new version API interface; if the change type is function symbol change, generating an adaptation function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function name of the adaptation function being the same as the function name of the old version API interface, and internally calling the new version API interface by linking to a new library or dynamically looking up symbols; if the change type is function return value change, generating a wrapper function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function parameters of the wrapper function being the same as the return value of the old version API interface, and internally calling the new version API interface after adapting the return value, and the return value adaptation including part or all of assigning default values, type conversion, and format adjustment to the return values between the old version API interface and the new version API interface.

[0009] Optionally, when packaging the new version target library and the compatibility adaptation layer library into an installation package in step S1, it further includes packaging the compatibility adaptation layer library into the new version target library or as a sub-package of the new version target library.

[0010] Optionally, in step S3, loading the compatibility adaptation layer library prior to the new version target library is one of the following two methods: Method 1: Based on the startup script of the application added in the installation package, by setting the LD_PRELOAD environment variable in the Linux system to load the compatibility adaptation layer library and then execute the new version target library of the application, so that the compatibility adaptation layer library is loaded prior to the new version target library; Method 2: After installing the compatibility adaptation layer library to the system standard path, by editing the / etc / ld.so.preload file in the Linux system and adding the compatibility adaptation layer library to the preloading list, so that the compatibility adaptation layer library is loaded prior to the new version target library.

[0011] Optionally, the packaging stage of the application is integrated into the continuous integration and continuous deployment pipeline, and the update operations of the underlying libraries in the continuous integration and continuous deployment pipeline are monitored. If an update operation of the underlying library is detected, the packaging stage of the application is started for the application in the underlying library, and the obtained installation package is tested. If it passes, the updated installation package is released.

[0012] In addition, the present invention also provides an intelligent adaptation layer automatic generation system based on API changes, including a microprocessor and a memory connected to each other. The microprocessor is programmed or configured to execute the intelligent adaptation layer automatic generation method based on API changes.

[0013] In addition, the present invention also provides a computer-readable storage medium, in which a computer program or instruction is stored. The computer program or instruction is programmed or configured to execute the intelligent adaptation layer automatic generation method based on API changes through a processor.

[0014] In addition, the present invention also provides a computer program product, including a computer program or instruction. The computer program or instruction is programmed or configured to execute the intelligent adaptation layer automatic generation method based on API changes through a processor.

[0015] Compared with the prior art, the present invention can mainly achieve the following beneficial effects: 1. High degree of automation and reduced maintenance cost: The tool automatically detects and generates adaptation code, and developers do not need to manually code a large amount of compatibility logic, significantly reducing the human maintenance cost and the risk of errors. 2. Improve the long-term availability of software packages: After applying the present invention, software packages such as RPM can still work properly when the underlying library is upgraded, significantly extending the available life cycle of the software. Even if API changes are caused by system updates years later, with the help of the automatic adaptation layer, the original binary programs can still run seamlessly, improving the robustness and reliability of the software. 3. Wide generality and scope of application: The method of the present invention is applicable to API changes of various C / C++ software libraries, and is particularly suitable for binary compatibility maintenance in the RPM software package ecosystem of the Linux system. Whether it is the maintainers of the operating system distribution, third-party software developers, or enterprise IT operation and maintenance teams, they can all use this system to cope with the challenges brought by API incompatibility and reduce the situation of application failure caused by library upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a schematic diagram of the basic process of the method according to the embodiment of the present invention.

[0017] Figure 2 It is a schematic diagram of the module architecture in the embodiment of the present invention.

[0018] Figure 3This is a schematic diagram of the API change detection process in an embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram of the automatic generation process of the adaptation layer code in an embodiment of the present invention. Detailed implementation manners

[0020] In order to enable those skilled in the art of this technology to better understand the technical solution of the present invention, the technical solution of the present invention will be further described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0021] As Figure 1 shown, the automatic generation method of the intelligent adaptation layer based on API changes in this embodiment includes the following steps: S1. In the packaging stage of the application program, obtain the old version API interface definition and the new version API interface definition of the software package; Perform API change detection according to the old version API interface definition and the new version API interface definition; Generate adaptation code according to the API change detection result; Compile the source code of the application program into a new version target library, compile the adaptation code to generate a compatible adaptation layer library, and package the new version target library and the compatible adaptation layer library into an installation package; S2. In the installation stage of the application program, install the new version target library and the compatible adaptation layer library into the target directory; S3. In the running stage of the application program, load the compatible adaptation layer library prior to the new version target library, and take over the processing of the old version API interface through the compatible adaptation layer library and transfer and call the new version API interface in the new version target library to achieve the compatible adaptation of the application program API change.

[0022] As Figure 2As shown in the figure, in this embodiment, an API change detection module 103 and an adaptation code generation module 104 are adopted. After the old version API interface definition acquisition module 101 acquires the old version API interface definition of the software package (such as the header file of the old library or the exported symbols extracted from the binary library), and the new version API interface definition acquisition module 102 acquires the new version API interface definition (such as the header file of the new library or the exported symbols extracted from the binary library), the API change detection module 103 performs API change detection according to the old version API interface definition and the new version API interface definition, and the adaptation code generation module 104 generates adaptation code according to the API change detection result. Then, the compilation and packaging module can compile the source code of the application program into a new version target library 106, compile the adaptation code to generate a compatible adaptation layer library 105 (such as libcompat.so), and the application program 107 preloads the compatible adaptation layer library 105 and the new version target library 106 through the LD_PRELOAD mechanism during runtime, so that the calls to the old API are intercepted and processed by the compatible adaptation layer library 105, and the implementation functions in the new version target library 106 are called to achieve seamless connection and compatibility between the old and new APIs. Among them, LD_PRELOAD (Linux dynamic linker preloading mechanism) is a runtime dynamic linking mechanism provided by the Linux system, which allows users to specify a shared library when starting a program and preferentially load the symbols in the shared library before the default linked libraries are loaded.

[0023] As Figure 2 shown in the figure, in this embodiment, the API change detection module 103 specifically performs API change detection based on AST (Abstract Syntax Tree) and ABI (Application Binary Interface) analysis. Among them, ABI (Application Binary Interface) is the interface specification followed by software modules when interacting at the binary level, which defines function call conventions (such as parameter passing methods, return value processing), memory layouts (such as structure alignment, field order), symbol naming methods, system call mechanisms, etc. AST (Abstract Syntax Tree) is a tree-like representation of the source code structure used to express the syntax structure of a program. Each node represents a structural element in the program, such as function definitions, variable declarations, expressions, etc.

[0024] As Figure 3 shown in the figure, in step S1 of this embodiment, performing API change detection according to the old version API interface definition and the new version API interface definition includes: Taking the old version API interface definition (such asFigure 3 As shown at 201 in [reference], an abstract syntax tree of the old version API interface definition is generated using a compilation front-end tool (such as the Clang front-end), as Figure 3 shown at 203 in [reference]; An abstract syntax tree of the new version API interface definition (such as Figure 3 shown at 202 in [reference]) is generated using a compilation front-end tool (such as the Clang front-end), as Figure 3 shown at 204 in [reference]; wherein, the old version API interface definition can be from an old version library header file, and the new version API interface definition can be from a new version library header file; The abstract syntax trees of the old version API interface definition and the new version API interface definition are subjected to abstract syntax tree difference detection to obtain an abstract syntax tree difference detection result, as Figure 3 shown at 205 in [reference]; The binary interfaces of the old version API interface definition and the new version API interface definition are compared using an ABI difference analysis tool (such as abidiff provided by libabigail) to obtain an ABI difference analysis result, as Figure 3 shown at 206 in [reference]; wherein libabigail (ABI Generic Analysis and Instrumentation Library) is an open-source toolset dedicated to analyzing Linux binary files in ELF format (such as.so shared libraries) and detecting ABI changes. Its core components include abidiff (for difference comparison) and abidw (for extracting DWARF debugging information). By comparing the binary interfaces of the old and new version libraries, symbol-level additions, deletions, or incompatible changes are found to supplement the AST detection result (abstract syntax tree difference detection result); The abstract syntax tree difference detection result and the ABI difference analysis result are combined to generate an API change list. Each entry in the API change list corresponds to an API change, as Figure 3 shown at 207 in [reference]. Each entry may include newly added or removed functions, functions with parameter modifications, and other binary-incompatible details, providing a basis for automatically generating adaptation code later.

[0025] In this embodiment, the AST analysis interface provided by Clang and the ABI comparison tool are used to implement the automatic detection of library API changes. First, obtain the interface definition information of the old version library and the new version library, such as the list of header files or the symbol signatures extracted from the binary library. In this embodiment, the Clang compiler front-end is used to parse the header files of the old version to generate an Abstract Syntax Tree (AST), and record the interface elements such as external functions and global variables therein; similarly, parse the header files of the new version to generate an AST and extract the corresponding interface information. By comparing the two ASTs, the differences in the API definitions at the source code level can be found, such as whether the function declarations have been modified. It is worth mentioning that AST analysis can detect high-level syntax changes such as parameter lists, types, and function names, but for binary-level compatibility (such as data type size adjustment and changes in the internal offsets of structures), an ABI tool is still needed. For this reason, the system further uses the ABI difference analysis library libabigail to compare the compiled binary libraries. Using the abidiff tool provided by libabigail, compare the ELF symbol tables and type information of the old version library and the new version library to obtain a detailed ABI difference report. For example, if a certain function is removed in the new version library, abidiff will report that the symbol does not exist in the new library; another example is that if the size of a certain structure changes, abidiff will also prompt the changed entries of ABI incompatibility. By parsing the output of abidiff, the system can collect the change lists at the function level and data type level. Combining the AST differences and the ABI differences results, the change detection module generates the final API change list. Each entry in the list describes an incompatible change point, including: the interface name involved, the change type (addition / removal / parameter modification / type modification, etc.), and the difference description between the old version definition and the new version definition. For example: the parameters of the function foo() are increased from int to int and char*, the return type of the function bar() is changed from float to double, the symbol baz is removed in the new version, etc. These information will be used as the basis for generating the adaptation layer code in the next step. As an alternative implementation, the information recorded in each entry of the API change list in this embodiment includes the API interface name involved, the API change description, and the change type, and the change type includes some or all of function parameter changes, function symbol changes, and function return value changes.

[0026] As Figure 4 shown, in step S1 of this embodiment, generating adaptation code according to the API change detection result includes traversing each entry in the API change list (as Figure 4 shown in 301 therein), and selecting the corresponding code snippet from the predefined adaptation code template library according to the change type of this entry (as Figure 4 shown in 302 therein) to generate the corresponding adaptation code (as Figure 4303 in ), for example, if the parameter list changes, a wrapper function code is generated, which calls the new function internally and converts the parameters; if the symbol name changes, a function alias is generated or a function implementation that calls the new symbol is generated. Finally, all the generated adaptation codes are compiled and linked to generate the final compatible adaptation layer shared library (such as libcompat.so) (such as Figure 4 Output the adaptation layer library for deployment. At this point, the adaptation layer library is completed. When the application is running, the old API call can be intercepted and compatible by loading the library (such as Figure 4 305 in FIG. 1 ).

[0027] After obtaining the API difference list, the system will automatically generate the corresponding adaptation layer source code according to the different change types. The adaptation layer code is essentially some wrapper functions and alternative implementations, which are used to "translate" the old interface at the binary level. In this embodiment, when selecting the corresponding code snippet from the predefined adaptation code template library to generate the corresponding adaptation code, it includes: If the change type is function parameter change, a wrapper function is generated for the old version API interface and the new version API interface to achieve adaptation between the old version API interface and the new version API interface. The function parameters of the wrapper function are the same as those of the old version API interface, and the new version API interface is called after the function parameters are adapted internally. The parameter adaptation includes assigning default values, type conversion, and format adjustment to the function parameters between the old version API interface and the new version API interface. For example, the function int calc(int a) in the old version library becomes int calc_new(int a, int b) in the new version (one more parameter), and the following adaptation code is generated: extern int calc_new(int a, int b); / / declare new version API function / / Compatible with the adapter function, implement the old API interface, and call the new API function internally int calc(int a) { / / Provide default parameters to call the new function int default_b = 0; return calc_new(a, default_b); } In the above code, the adaptation layer defines the old interface calc(int) function. Its implementation internally calls the new interface calc_new(int, int) and provides a default value (such as 0) for the newly added parameter. The generated adaptation layer library will export the symbol calc, so that when the old version of the application calls calc, it actually calls the implementation provided by the adaptation layer, and then executes the calc_new function of the new version library within the adaptation layer. For the case where the parameter type changes, the wrapper function can also perform type conversion or data format adjustment before calling the new function to ensure that it matches the type expected by the new API.

[0028] If the change type is a function symbol change, an adaptation function is generated for the old version API interface and the new version API interface to achieve the adaptation between the old version API interface and the new version API interface. The function name of the adaptation function is the same as that of the old version API interface, and internally it calls the new version API interface by linking to the new library or dynamically looking up symbols; for example, if the old library has a function void oldFunc() which is renamed to void newFunc() in the new version, the adaptation layer can implement oldFunc() and internally call newFunc().

[0029] If the change type is a function return value change, a wrapper function is generated for the old version API interface and the new version API interface to achieve the adaptation between the old version API interface and the new version API interface. The function parameters of the wrapper function are the same as the return value of the old version API interface, and internally it calls the new version API interface after adapting the return value. The return value adaptation includes some or all of assigning a default value, type conversion, and format adjustment to the return value between the old version API interface and the new version API interface.

[0030] When packaging the new version target library and the compatible adaptation layer library into an installation package in step S1 of this embodiment, it also includes packaging the compatible adaptation layer library into the new version target library or as a subpackage of the new version target library.

[0031] In step S3 of this embodiment, loading the compatible adaptation layer library prior to the new version target library is one of the following two methods: Method 1, based on the startup script of the application added in the installation package, load the compatible adaptation layer library by setting the LD_PRELOAD environment variable in the Linux system and then execute the new version target library of the application, so that the compatible adaptation layer library is loaded prior to the new version target library; Method 2, after installing the compatible adaptation layer library to the system standard path, edit the / etc / ld.so.preload file in the Linux system to list the compatible adaptation layer library in the preloading list, so that the compatible adaptation layer library is loaded prior to the new version target library.

[0032] For example, in the scenario of function symbol changes and the general case of symbol interception through LD_PRELOAD, the adaptation code can use dlsym to obtain the address of the new library function for calling. The following is an example of intercepting an old function through LD_PRELOAD and calling a new function: #define _GNU_SOURCE / / To use RTLD_NEXT #include<dlfcn.h> #include<stdio.h> / / Assume the new signature of the target function in the new library is int calc(int a, int b), / / that is, an additional parameter is added to the old API calc typedef int (*calc_new_func_t)(int, int); int calc(int a) { / / Intercept the call to the old API calc(int) and instead call the new API calc(int,int) static calc_new_func_t real_calc_new = NULL; if (real_calc_new == NULL) { / / Obtain the pointer to the actual function in the new library (assuming the symbol name in the new library is still calc) real_calc_new = (calc_new_func_t)dlsym(RTLD_NEXT, "calc"); if (real_calc_new == NULL) { fprintf(stderr, "Error: new calc function not found\n"); return -1; } } / / Call the new function to implement the compatibility function return real_calc_new(a, 0); } The above code snippet simulates the mechanism by which the adaptation layer library intercepts symbols through LD_PRELOAD. The adaptation layer implements a function calc(int) with the same name and signature as the old API. Since the adaptation layer library is loaded prior to the new library, it intercepts the application's call to calc. Inside the adaptation function, the address of the implementation of calc in the next layer's actual library (i.e., the new library) is retrieved using dlsym(RTLD_NEXT, "calc"), and then it is called. In this way, without interrupting the application's call flow, the adaptation layer hooks the old interface call to the new implementation. It should be noted that if the names of the old and new functions are different, the adaptation layer can also directly call the new function name or link to the new library when compiling the adaptation layer to resolve the new symbol. In any case, the generated adaptation code should ensure that the functions required by the old interface are executed in the new library, thus being transparent to the upper-layer application.

[0033] This embodiment integrates the above API difference detection and adaptation layer code generation process into the build and release process of the RPM software package. With this integration, when maintaining personnel build the RPM package of the application, they do not need to worry about the compatibility issues of underlying library changes, and the system will automatically inject the adaptation layer to ensure compatibility. The integration scheme mainly includes the following steps: 1) Pre-build check: In the preparation stage of RPM packaging (such as the %prep stage), introduce an automated script or tool to perform ABI checks on the target dependent libraries in the current build environment. This tool reads the library interfaces expected by the application (which can be obtained from the interface signatures recorded in the previous build or the pre-saved old version header files), and compares them with the interfaces of the current version libraries in the system. If incompatible changes are detected, the tool will generate a difference report and the source code of the adaptation layer. Otherwise (no API changes), skip the subsequent adaptation layer build steps.

[0034] 2) Adaptation layer compilation: In the build stage of RPM packaging (such as in %build), if the source code of the adaptation layer was generated in the previous step, call the compiler to compile it into a shared library. For example, use gcc -fPIC -shared compat_layer.c -o libcompat.so to compile the generated compat_layer.c into libcompat.so. When compiling, link to the new version library as needed (to ensure that the adaptation functions can resolve new symbols), and enable the necessary compilation options (such as -ldl to use dlsym). The following gives an example of an RPM spec file snippet to show how to integrate the build and installation of the adaptation layer: # Example of integrating the adaptation layer in the RPM packaging specification file (.spec) %prep #... Normal source code preparation... # Run the API compatibility check tool (assuming api_diff_tool exists) to generate differences and adaptation code api_diff_tool --old-headers old_version_headers.h --new-headers / usr / include / newlib.h --output compat_layer.c %build # Compile the generated adaptation layer source code into a shared library gcc -fPIC -shared compat_layer.c -o libcompat.so -ldl %install # Install the adaptation shared library to the target path install -m 755 -D libcompat.so %{buildroot}%{_libdir} / libcompat.so # Install the application running script, set the LD_PRELOAD environment variable to load the adaptation library echo -e '#! / bin / sh\nLD_PRELOAD= / usr / lib / libcompat.so exec / usr / bin / myapp "$@"'>run_myapp.sh install -m 755 -D run_myapp.sh %{buildroot}%{_bindir} / run_myapp 3) Release and Deployment: After the packaging is completed, the released RPM already contains the application and the corresponding adaptation layer shared library (if generated). To make the adaptation layer take effect at runtime, two methods can be used: First, as in the above example, add the startup script of the application to the installation package, and load the adaptation library by setting the LD_PRELOAD environment variable before executing the actual program; Second, after installing the adaptation layer library to the system standard path, manually edit the system's / etc / ld.so.preload file and add this library to the preloading list (so that the system will preload this compatibility library when starting any application). Considering that the second method has a larger impact range, it is usually preferred to configure a specific startup script for the target application and limit LD_PRELOAD only for this application.

[0035] As an alternative implementation, in this embodiment, the packaging phase of the application is integrated into the continuous integration and continuous deployment (CI / CD) pipeline, and the update operations of the basic libraries in the continuous integration and continuous deployment pipeline are monitored. If an update operation of the basic library is detected, the packaging phase of the application is started for the application in the basic library, and the obtained installation package is tested. If it passes, the updated installation package is released. After introducing the method of this embodiment into the continuous integration / continuous deployment pipeline, when the basic library is updated, the CI script can run ABI checks and adapter layer generation, and repackage and test the updated adapter layer together with the application. If the test passes, the updated RPM is released, implementing an automated compatibility maintenance process. This greatly reduces manual intervention and ensures the stable availability of applications in enterprise-level distributions during long-term maintenance.

[0036] Through the above integration solution, the building process of RPM packages becomes more intelligent: whenever the environment changes and causes API incompatibility, the system of the present invention will automatically generate and inject adaptation layer code, so that the finally produced software package can "adapt" to the changes in the target operating environment. For the operation and maintenance team, after deploying such an RPM package, the compatible operation of the application can be guaranteed without additional operations; for the distribution maintainers, the pressure on the application developers to update in a timely manner due to underlying changes is also reduced. The method of this embodiment provides a general-purpose compatibility solution for the RPM ecosystem and has high practical value in practice. This embodiment has the following key innovations: (1) Automated mechanism for API change detection: An automatic detection method that combines source code AST analysis and binary ABI comparison is proposed. Traditional practices often require manual inspection of changes in the new version of the library or the use of limited ABI compatibility checking tools; while this embodiment uses abstract syntax tree (AST) and application binary interface (ABI) analysis techniques to automatically compare the interface definitions of the old and new versions of the library files. The system extracts the AST representation of the header file through the Clang compilation front end, and combines the ABI difference analysis tool (such as abidiff of libabigail) to compare the compatibility changes of function symbols, and accurately locates the change points of the API. By using Clang to generate an abstract syntax tree and combining with the abidiff tool, changes such as the addition, deletion, or parameter type change of function interfaces can be comprehensively and accurately identified. This automated mechanism reduces manual participation and improves the accuracy and efficiency of change detection. (2) Intelligent generation of adaptation layer code: In the prior art, when there is an incompatible change in the library interface, developers usually need to manually write an "adaptation layer" or modify the application code to adapt to the new interface. This embodiment innovatively provides a template-driven automatic generation scheme for adaptation code. Adaptation layer source code is automatically generated for the detected API change types. If a function parameter is added or the type is changed, a corresponding wrapper function is generated to fill and convert the parameters and then call the new function; if the function symbol name is changed or removed, a new function implementation with the old interface signature is generated, and the new version function or equivalent function code is called internally. The generation process uses a predefined code template library, and appropriate code snippets are inserted according to the change type to achieve intelligent code synthesis. According to the detected change type, the system selects appropriate code snippets from the predefined template library to assemble adaptation functions or symbol mapping codes, thereby automatically generating the complete compatible layer source code and compiling it into a library. Such intelligent generation avoids the cumbersome and error-prone adaptation code written manually and greatly improves the development efficiency. (3) LD_PRELOAD runtime compatibility technology and 3. Runtime interception and call redirection: This embodiment uses the LD_PRELOAD mechanism to achieve seamless redirection of old interface calls, which is a clever runtime compatibility scheme.Compared with the traditional adaptation method by modifying source code or binary rewriting, the new solution does not require changing the existing application. Instead, it only needs to preload a compatibility library at runtime to intercept old API calls and convert them to the new library implementation. This method is transparent to the application, and the compatibility layer can be independently deployed, ensuring plug-and-play support for old-version applications, with higher flexibility and convenience. Using this mechanism, the old API calls issued by the application will first be linked to the adaptation layer library, and the adaptation code will take over the processing and transfer to the implementation function in the new version library, thus achieving compatibility adaptation at the binary level without modifying the application itself. (4) Integration with the RPM building process: In this embodiment, the above detection and generation mechanisms are integrated into the building and release process of software packages. When a new version RPM package of the target library is released, it can automatically trigger the interface difference detection and the building and packaging of the compatibility layer library. This integrated innovation enables the compatibility adaptation layer to be released together with the new version library, reducing additional deployment steps and ensuring that users obtain compatibility support for old applications while upgrading the library. This advantage is rare in the existing technologies, greatly improving the smoothness and reliability of system upgrades. The API change detection and adaptation code generation process are seamlessly embedded in the software package building process of RPM. When building the RPM package, the API differences between the old and new libraries are automatically checked, the adaptation layer code is generated and compiled into a shared library, and then this shared library is packaged into the RPM (or as a subpackage). The packaged application RPM can have the support of the adaptation layer when installed, and at runtime, it ensures the priority loading of the adaptation layer library through scripts or environment settings to ensure the normal operation of calling the new library on the target system, achieving the effect of "one build, compatible with multiple versions". In summary, this embodiment realizes the function of making old applications compatible with new library interfaces without modification through automated API difference detection, intelligent adaptation code generation, and combined with the LD_PRELOAD runtime redirection technology. In addition, integrating this mechanism into the standard building and release process makes it more practical. These innovative points provide unique advantages compared with the existing technologies, significantly reducing the maintenance cost and improving the compatibility and stability of software evolution.

[0037] In addition, this embodiment also provides an intelligent adaptation layer automatic generation system based on API changes, including a microprocessor and a memory connected to each other, and the microprocessor is programmed or configured to execute the intelligent adaptation layer automatic generation method based on API changes.

[0038] In addition, this embodiment also provides a computer-readable storage medium, in which a computer program or instruction is stored, and the computer program or instruction is programmed or configured to execute the intelligent adaptation layer automatic generation method based on API changes through a processor.

[0039] In addition, this embodiment also provides a computer program product, including a computer program or instruction, which is programmed or configured to execute the automatic generation method of the intelligent adaptation layer based on API changes through a processor.

[0040] Those skilled in the art should understand that the technical solution provided by the present invention can be in the form of a method, a system, or a computer program product. Therefore, the present invention can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can adopt the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code. The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowchart and / or block diagram can also be implemented. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks. These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device realizes the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks. These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0041] The above is only the preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. An automatic generation method for an intelligent adaptation layer based on API changes, characterized in that, Including the following steps: S1. In the packaging stage of the application, obtain the old version API interface definition and the new version API interface definition of the software package; Perform API change detection based on the old version API interface definition and the new version API interface definition; Generate adaptation code according to the API change detection result; Compile the source code of the application into a new version target library, compile the adaptation code to generate a compatible adaptation layer library, and package the new version target library and the compatible adaptation layer library into an installation package; S2. In the installation stage of the application, install the new version target library and the compatible adaptation layer library into the target directory; S3. In the running stage of the application, load the compatible adaptation layer library prior to the new version target library, and take over the processing of the old version API interface through the compatible adaptation layer library and transfer and call the new version API interface in the new version target library to implement the compatible adaptation of the API change of the application.

2. The automatic generation method of the intelligent adaptation layer based on API change according to claim 1, wherein In step S1, performing API change detection based on the old version API interface definition and the new version API interface definition includes: Using a compilation front-end tool to generate an abstract syntax tree of the old version API interface definition from the old version API interface definition; Using a compilation front-end tool to generate an abstract syntax tree of the new version API interface definition from the new version API interface definition; Performing abstract syntax tree difference detection on the abstract syntax tree of the old version API interface definition and the abstract syntax tree of the new version API interface definition to obtain an abstract syntax tree difference detection result; Comparing the binary interfaces of the old version API interface definition and the new version API interface definition using an ABI difference analysis tool to obtain an ABI difference analysis result; Combining the abstract syntax tree difference detection result and the ABI difference analysis result to generate an API change list, and each entry in the API change list corresponds to an API change.

3. The automatic generation method of the intelligent adaptation layer based on API change according to claim 2, characterized in that The information recorded in each entry in the API change list includes the name of the API interface involved, the API change description, and the change type, and the change type includes some or all of function parameter change, function symbol change, and function return value change.

4. The automatic generation method of the intelligent adaptation layer based on API change according to claim 3, wherein In step S1, generating adaptation code according to the API change detection results includes traversing each entry in the API change list, and selecting a corresponding code snippet from a predefined adaptation code template library according to the change type of the entry to generate corresponding adaptation code, including: if the change type is function parameter change, generating a wrapper function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function parameters of the wrapper function being the same as those of the old version API interface, and internally calling the new version API interface after adapting the function parameters, where the parameter adaptation includes some or all of default value assignment, type conversion, and format adjustment for the function parameters between the old version API interface and the new version API interface; if the change type is function symbol change, generating an adaptation function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function name of the adaptation function being the same as that of the old version API interface, and internally calling the new version API interface by linking a new library or dynamically looking up symbols; if the change type is function return value change, generating a wrapper function for the old version API interface and the new version API interface to implement the adaptation between the old version API interface and the new version API interface, the function parameters of the wrapper function being the same as the return value of the old version API interface, and internally calling the new version API interface after adapting the return value, where the return value adaptation includes some or all of default value assignment, type conversion, and format adjustment for the return values between the old version API interface and the new version API interface.

5. The automatic generation method of the intelligent adaptation layer based on API changes according to claim 1, wherein When packaging the new version target library and the compatibility adaptation layer library into an installation package in step S1, it also includes packaging the compatibility adaptation layer library into the new version target library or as a subpackage of the new version target library.

6. The method for automatically generating an intelligent adaptation layer based on API changes according to claim 1, characterized in that In step S3, loading the compatibility adaptation layer library prior to the new version target library is one of the following two methods: Method 1, based on the startup script of the application added in the installation package, loading the compatibility adaptation layer library by setting the LD_PRELOAD environment variable in the Linux system and then executing the new version target library of the application, so as to load the compatibility adaptation layer library prior to the new version target library; Method 2, after installing the compatibility adaptation layer library to the system standard path, by editing the / etc / ld.so.preload file in the Linux system, listing the compatibility adaptation layer library in the preloading list, so as to load the compatibility adaptation layer library prior to the new version target library.

7. The method for automatically generating an intelligent adaptation layer based on API changes according to claim 1, wherein The packaging stage of the application is integrated into the continuous integration and continuous deployment pipeline, and monitors the update operations of the basic library in the continuous integration and continuous deployment pipeline. If an update operation of the basic library is detected, the packaging stage of the application is started for the application in the basic library, and the obtained installation package is tested. If it passes, the updated installation package is released.

8. An intelligent adaptation layer automatic generation system based on API changes, comprising a microprocessor and a memory connected to each other, characterized in that, The microprocessor is programmed or configured to execute the method for automatically generating an intelligent adaptation layer based on API changes according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instruction is programmed or configured to execute, through a processor, the method for automatically generating an intelligent adaptation layer based on API changes according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instruction is programmed or configured to execute, through a processor, the method for automatically generating an intelligent adaptation layer based on API changes according to any one of claims 1 to 7.

Images