Application packaging method, storage medium, electronic device and program product

By installing the source system's basic runtime environment and setting the dynamic linker path in the packaging system, the compatibility and resource overhead issues of cross-system applications are resolved, enabling stable operation and efficient deployment of applications on different systems.

CN120803477AActive Publication Date: 2025-10-17ZTE CORP
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202510895946.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-30
Publication Date
2025-10-17
Estimated Expiration
2045-06-30

AI Technical Summary

Technical Problem

In the existing technology, cross-system applications have compatibility issues and large resource overhead during runtime. Especially in multi-command application scenarios, frequent sandbox startup and resource allocation lead to performance degradation and limited interaction between applications and systems.

Method used

The original basic operating and development environment of the source system is installed through the package management tool in the packaging system to ensure system environment consistency. The dynamic link loader path of the control program is set as the placement path of the loader inside the package. The application files are centrally located in the packaging directory to generate the application installation package.

Benefits of technology

It solves the compatibility issues of cross-system applications, improves operational stability and efficiency, reduces resource consumption, and ensures the correct operation of applications on different systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120803477A_ABST
    Figure CN120803477A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides an application program packaging method, a storage medium, an electronic device and a program product, and the method comprises the steps that a source system comprising original basic operation and original development environment of a packaged application program is installed in a packaging system through a package management tool, and the package management tool of the packaging system is the same as that of the source system; the source system is a system which is originally expected to run before the application program is packaged; compiling the control program in the source system, setting a dynamic link loader path of the control program as a placement path of a loader in a package after the package is installed, and storing the control program in a package directory; and producing and generating the application program installation package according to the file in the packaging directory. Through the embodiment of the invention, the problems of incompatibility and relatively high overhead during running of the cross-system application program generated by packaging in related technologies are solved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of software packaging, and in particular, to a packaging method of an application program, a storage medium, an electronic device and a program product. BACKGROUND

[0002] In the field of software packaging, the packaging of an application program is an important link for ensuring that the application program and its dependent components can run stably in different system environments. Traditional application packaging methods, such as deb and rpm, although provide convenience for the installation and management of software, are limited to specific system distribution versions, resulting in the need for recompilation and packaging of the application when running on different systems, increasing the complexity and cost of application distribution.

[0003] In order to solve the problem of software compatibility across system distribution versions, several cross-system packaging technologies have been developed, such as AppImage, Flatpak and Snap, although these technologies have achieved cross-system running of software to some extent, they have certain limitations and problems. In related technologies, when packaging an application program, a sandbox is created, thus consuming additional system resources, especially in multi-command application scenarios, frequent sandbox startup and resource allocation result in significant performance degradation. And because the application program runs in a sandbox environment when packaging, the interaction of the application program with other parts of the system is limited, reducing the flexibility of the application, especially in scenarios where system native commands need to be called or specific system resources need to be accessed. SUMMARY

[0004] Embodiments of the present application provide a packaging method of an application program, a storage medium, an electronic device and a program product to at least solve the problem that a cross-system application program generated by related technologies is incompatible and has high overhead when running.

[0005] According to an embodiment of the present application, a packaging method of an application program is provided, comprising: installing a source system including an original base running and an original development environment of a packaged application program in a packaging system through a package management tool, wherein the package management tool of the packaging system is the same as that of the source system, and the source system is a system in which the application program is originally intended to run before being packaged; compiling a control program in the source system, setting a dynamic link loader path of the control program to a placement path of an internal loader after package installation, and storing the control program under a packaging directory; and generating an application program installation package according to the files under the packaging directory.

[0006] According to another embodiment of the present application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is set to execute the steps in the above method embodiment when running.

[0007] According to still another embodiment of the present application, an electronic device is also provided, comprising a memory and a processor, the memory having stored therein a computer program, the processor being arranged to execute the computer program to perform the steps of the above method embodiments.

[0008] According to still another embodiment of the present application, a computer program product is also provided, comprising a computer program which, when executed by a processor, implements the steps of the above method embodiments.

[0009] Through the above embodiments of the present application, the environment of the source system is copied and installed in the packaging system, ensuring that the system environment in the packaging process is consistent with the environment originally expected by the application program to run. This avoids the problem of application packaging failure or abnormal running due to environment differences, and enhances the running stability of the application program on different systems. Compiling the control program in the source system can ensure that the control program is compatible with the dynamic link loader of the source system. Pointing the dynamic link loader path of the control program to the loader inside the package means that the application program will use the dynamic link loader provided by the package during runtime, rather than the system default loader. This not only avoids the problem of inconsistent dynamic link loader versions between different systems, but also allows the control program to dynamically correct the environment variables during runtime, ensuring that the library files required for the correct running of the application program can be found. Therefore, the problem of incompatibility and large overhead of the cross-system application program packaged in the related art during runtime can be solved. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 is a hardware structure block diagram of a computer terminal of the packaging method of the application program according to an embodiment of the present application;

[0011] Figure 2 is a flowchart of the packaging method of the application program according to an embodiment of the present application;

[0012] Figure 3 is a structural block diagram of a packaging device of the application program according to an embodiment of the present application;

[0013] Figure 4 is a flowchart of the packaging method of the application program according to another embodiment of the present application;

[0014] Figure 5 is a deployment structure diagram of the application installation package according to an embodiment of the present application;

[0015] Figure 6 is a control program processing flowchart according to an embodiment of the present application;

[0016] Figure 7 is a control program processing flowchart according to another embodiment of the present application. DETAILED DESCRIPTION

[0017] Hereinafter, the embodiments of the present application will be described in detail with reference to the accompanying drawings and examples.

[0018] It should be noted that the terms "first", "second" and the like in the description and claims of the present application and the above drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence.

[0019] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking the case of running on a computer terminal, Figure 1 is a hardware structure diagram of the computer terminal on which the method embodiments of the present application run. As shown in Figure 1 , the computer terminal can include one or more (only one is shown in Figure 1 ) processor 102 (the processor 102 can include but not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above computer terminal can also include a transmission device 106 for communication function and an input and output device 108. Those skilled in the art can understand that Figure 1 The structure shown is only schematic, which does not limit the structure of the above computer terminal. For example, the computer terminal can also include more or less components than Figure 1 shown, or have a different configuration from Figure 1 shown.

[0020] The memory 104 can be used to store computer programs, for example, software programs of application software and modules, such as the computer program corresponding to the packaging method of the application program in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above method. The memory 104 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include a memory remotely arranged with respect to the processor 102, which can be connected to the computer terminal through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0021] The transmission device 106 is configured to receive or send data via a network. The network can include a wireless network provided by a communication provider of a computer terminal. In one embodiment, the transmission device 106 includes a network interface controller (NIC) that can be connected to other network devices through a base station to communicate with the Internet. In one embodiment, the transmission device 106 can be a radio frequency (RF) module that is configured to communicate with the Internet wirelessly.

[0022] Figure 2 A flowchart of a packaging method of an application according to an embodiment of the present application is shown in FIG. 2, which includes the following steps: Figure 2

[0023] In step S202, a source system including an original basic running and an original development environment of the application to be packaged is installed in a packaging system by a package management tool, wherein the package management tool of the packaging system is the same as that of the source system, and the source system is a system in which the application is originally intended to run before being packaged.

[0024] In one embodiment, the packaging method of the application is applied to a Linux system, and the packaging system and the source system are the same Linux system or different versions of Linux systems with the same architecture.

[0025] In the exemplary embodiment of the present application, the source system including the original basic running and the original development environment of the application to be packaged is installed in the packaging system by the package management tool, including: installing the source system including the original basic running and the original development environment of the application in a temporary directory in the packaging system by using the same package management tool and a packaging configuration file as the source system; wherein the packaging configuration file includes soft link information and a software package repository address, the soft link information is used to indicate a list of files that need to be established as soft links, and the software package repository address is used to provide software packages and the original running environment included in the application.

[0026] It should be noted that the selection and use of the package management tool are crucial to the packaging process, ensuring that the environment of the packaging system is consistent with the source system, and all dependencies can be accurately collected. Through the standardized processing of the tool, it is ensured that the finally generated application installation package can run on different system distributions without additional environment configuration or dependency installation. This greatly simplifies the deployment and running of cross-system applications, improves the portability of software and user experience.

[0027] ​In one embodiment, the soft link information will be used for the installation enabling stage of the package, providing file information interacting with the system, including scripts, configuration files, log files, data storage files, service configuration files, etc. that will be used during the application running process, and the files that need to be filled in the application running process will be accessed in the specified path.

[0028] In the exemplary embodiments of the present application, the packaging configuration file further comprises at least one of the following: an application program name, used to indicate the name of the packaged application program; an application program version number, used to indicate the version number of the packaged application program; an application program description; a software package name list, used to indicate the information of the packaged object; and installation and uninstallation scripts, used to customize the actions during the installation and uninstallation of the application program.

[0029] In the exemplary embodiments of the present application, before compiling the control program lines in the source system, the method further comprises: extracting the files in the software package from the source system, collecting the dependent libraries and the basic libraries required for the software package running based on the files, wherein the basic libraries comprise library files related to the dynamic link loader; resetting the path of the dynamic link loader in the executable and linkable format (ELF) files in the files, the basic libraries and the dependent libraries to an absolute path, the absolute path pointing to the placement path of the loader inside the package after the package is installed; removing the runtime library paths of all the ELF files, and storing all the processed files according to the original directory structure under the packaging directory.

[0030] It should be noted that the path of the dynamic link loader in the executable and linkable format ELF files in the files, the basic libraries and the dependent libraries is reset to an absolute path, because the installation and deployment path of the application package files will be fixed during packaging, and after the application package is installed, the application files in the package will be deployed in the expected specified location.

[0031] In the embodiments of the present application, the runtime library paths (rpath) of all the ELF files are removed, and the purpose of this operation is to prevent the runtime library paths from interfering with the search for dynamic libraries. Then all the extracted files are stored according to the original directory structure under a newly created packaging directory.

[0032] In the exemplary embodiments of the present application, the dependent libraries required for the software package running are collected based on the files, comprising: collecting the dependent libraries by using the List Dynamic Dependencies (ldd) command on all the dynamic link files in the software package, obtaining the shared libraries and paths dependent on the dynamic link, and using the ldd command on the shared libraries until all the dependent libraries are found.

[0033] The complete collection of library dependencies ensures that all dynamic library dependencies required for running the application, including direct and indirect dependencies, can be completely collected when the application is packaged. The ldd command is used to list the dynamic link dependencies of an executable file or a shared library. By recursively using ldd, all shared libraries directly or indirectly called by the application can be found, thereby avoiding errors caused by missing dependent libraries when running on the source system.

[0034] In the exemplary embodiments of the present application, the application installation package is generated according to the files in the packaging directory, including: generating the application installation package from the management program, the metadata, and the files in the packaging directory.

[0035] In the exemplary embodiments of the present application, the metadata includes at least one of the following: soft link information, the length and starting address of each region, application information, dependency information, provided function information, scripts to be executed before and after installation and uninstallation, and signature information.

[0036] In one embodiment, the management program is an executable program responsible for package installation, uninstallation, information viewing, signature verification, etc. When the package is executed as a program, the management program essentially operates the metadata information and the application data.

[0037] In the exemplary embodiments of the present application, the regions include: a management program region, a metadata region, and an application data region.

[0038] Step S204: Compiling the control program in the source system, setting the dynamic link loader path of the control program to the placement path of the internal loader after package installation, and storing the control program in the packaging directory.

[0039] In one embodiment, the control program is written in C language and is compiled in the source system because the dynamic link loader of the source system needs to be used, which can avoid the situation that the control program cannot be started due to incompatibility with the dynamic link loader. After compilation, the path of the dynamic link loader in the control program is set to the placement path of the loader after package installation.

[0040] Step S206: Generating the application installation package according to the files in the packaging directory.

[0041] In the exemplary embodiments of the present application, in the case of installing the application installation package, the management program of the application installation package installs and deploys the files in the application installation package to the specified newly created directory, and establishes soft links to the root directory according to the soft link information in the application installation package.

[0042] The application and all dependent files thereof are deployed in a designated new directory, instead of being scattered in the default directories of the system, thereby providing an isolated and controllable running environment for the application. Even if the application contains many different command entries, they can be organized and managed in an independent directory structure without conflicting with other applications or library files of the system.

[0043] The soft link is established under the root directory, so that the user or the system can operate the multi-entry command of the application as if it is a native command installed in the system, thereby achieving the technical effect of installing the application with multi-entry commands.

[0044] In the exemplary embodiments of the present application, the soft link is established under the root directory according to the soft link information in the application installation package, including at least one of the following: the soft link of the executable file is uniformly pointed to the control program of the application; the soft link file is pointed to the original pointing target; and other files are pointed to the corresponding entity files under the installation directory.

[0045] The soft link of the executable file is uniformly pointed to the control program of the application, which enhances the controllability and security of the application. The soft link file is pointed to the original pointing target, which maintains the link relationship of the original file. Other files are pointed to the corresponding entity files under the installation directory, which optimizes the file access efficiency and reduces resource consumption.

[0046] In the exemplary embodiments of the present application, when receiving the instruction to run the application, the control program sets the preloading dynamic library environment variable value to the path of the special dynamic library file; the special dynamic library is preferentially loaded by starting a sub-process, so that the execution function in the special dynamic library is called preferentially to the same name function in the system default library; and the actual program to be executed is started by calling the rewritten execution function in the sub-process.

[0047] In the exemplary embodiments of the present application, the execution function includes at least one of the following: an execution file path search function, a dynamic path modification function, a dynamic library search path function, a preloading dynamic library environment variable function, and an execution of the same name function in the system default library.

[0048] Those skilled in the art can clearly understand that the method according to the above-mentioned embodiments can be realized by means of software and necessary general hardware platform, of course, can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for making a terminal device (which can be a mobile phone, computer, server, or network device) execute the method described in each embodiment of the present application.

[0049] In the embodiment, a packaging device of an application program is also provided, which is used to realize the above-mentioned embodiments and preferred embodiments, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that realizes a predetermined function. Although the device described in the following embodiments is preferably realized in software, realization of hardware, or a combination of software and hardware, is also possible and contemplated.

[0050] Figure 3 is a structural block diagram of the packaging device of the application program according to the embodiment of the present application, as shown in Figure 3 The device includes an installation module 10, a storage module 20, and a production module 30.

[0051] The installation module 10 is used to install a source system including an original basic running and an original development environment of a packaged application program in a packaging system through a package management tool, wherein the package management tool of the packaging system is the same as that of the source system, and the source system is a system in which the application program is originally intended to run before being packaged;

[0052] The storage module 20 is used to compile a control program in the source system, set a dynamic link loader path of the control program to a placement path of an internal loader after package installation, and store the control program under a packaging directory.

[0053] The storage module 20 is also used to place all files in the packaged software package, all collected dependent libraries, and basic libraries under the packaging directory.

[0054] The production module 30 is used to produce an application program installation package according to the files under the packaging directory.

[0055] It should be noted that each of the above modules can be realized by software or hardware. For the latter, the following implementation manners can be used, but are not limited thereto: all of the above modules are located in the same processor; or each of the above modules is located in a different processor in any combination.

[0056] For the convenience of understanding the technical solutions provided by the application embodiments, the following describes the embodiments in conjunction with specific scenarios.

[0057] Scenario Embodiment One

[0058] Figure 4 is a flowchart of a packaging method of an application program according to still another embodiment of the application, as shown in Figure 4 The flowchart includes the following steps:

[0059] Step S401, input a packaging configuration file.

[0060] Specifically, the packaging configuration file includes at least one of the following: soft link information, software package repository address, application program name, application program version number, application program description, software package name list, and pre-installation and post-removal scripts.

[0061] Step S402, parse the packaging configuration file.

[0062] Specifically, the soft link information is used to indicate a list of files that need to be established as soft links, the installation enabling stage of the package, and the file information that interacts with the system, including scripts, configuration files, log files, data storage files, service configuration files, etc. that will be used during application running. In theory, only those files that will be accessed in the specified path during application running need to be filled in; the software package repository address is used to provide the software packages contained in the application program and the original running environment; the application program name is used to indicate the name of the packaged application program; the application program version number is used to indicate the version number of the packaged application program; the software package name list is used to indicate the information of the packaging object; and the pre-installation and post-removal scripts are used to customize the actions during application installation and removal.

[0063] Step S403, install and deploy a source system.

[0064] Specifically, a source system is installed and deployed using the repository in the configuration file. This step requires that the packaging system and the source system use the same software package management tool, so that the software package management tool can be used to install and deploy the source system in a temporary directory. The source system needs to be installed with the packaged software package and all its dependencies, as well as the gcc and glibc software packages and all their dependencies. Here, gcc is used to compile control programs, and glibc is used to provide a dynamic link loader so that each packaged application uses the dynamic link loader of the original system.

[0065] Step S404, extraction processing.

[0066] Extract all files of the software package from the source system, collect all dependent libraries and basic libraries, collect component information, dependency information, and post-installation and pre-uninstallation scripts of the software package. The dependent libraries are collected by using the ldd command on all dynamic link files of the target rpm, which lists the dependent shared libraries and paths, and then using the ldd command on the newly found shared libraries, repeating the above process until all dependent libraries are found. The basic library is mainly the library file related to the dynamic link loader. After the file collection is completed, the path of the dynamic link loader Interpreter of the ELF file is reset, and the path here is set to an absolute path, because the installation and deployment path of the application package file is fixed during packaging, and after the application package is installed, the application file in the package will be deployed in the expected specified location. Then remove the rpath of all ELF files, the purpose of this operation is to prevent rpath from interfering with the search for dynamic libraries. Then store all extracted files in the original directory structure under a newly created packaging directory.

[0067] Step S405, compile the control program.

[0068] The control program source code is placed in the source system for compilation. The control program is written in C language, and it is compiled in the source system because the dynamic link loader of the source system needs to be used, so that the control program can be started without compatibility problems with the dynamic link loader. After compilation, the path of the dynamic link loader Interpreter in the control program is set to the path where the loader is placed after the package is installed. Then the control program is also placed in the packaging directory.

[0069] Step S406, packaging.

[0070] Specifically, the management program, the collected various information, and the files in the packaging directory are made into a package.

[0071] Scenario embodiment two

[0072] In the example embodiment of the present application, in the case of installing an application installation package, the management program in the package header will install and deploy the files in the package to the specified newly created directory, and then establish a soft link to the root directory according to the soft link information in the metadata in the package.

[0073] The soft link information to be established is derived from the packaging configuration file and is divided into three categories: the first category is executable files, the second category is soft link files, and the third category is other files. The soft link positions to be established for the three categories of files are all the positions of the files when the original software package is installed, but the targets are different:

[0074] If it is an executable file, the soft link points to the control program of the application;

[0075] If it is a soft link file, keep the original soft link pointing target;

[0076] If it is other file, point to the corresponding entity file in the installation directory.

[0077] After the soft link is established, the deployment structure of the application package is as shown in Figure 5 Figure 5 The root directory ( / ) in the root directory is the basic directory of the system, and the root directory includes the bin / directory, the etc / directory and the installation directory. The bin / directory includes the executable file of the application program, and the program soft link is stored in the bin / directory, which points to the control program of the application; the etc / directory stores the soft link, and for the configuration file, the soft link directly points to the corresponding configuration file in the installation directory; the installation directory includes the control program, the bin / subdirectory and the etc / subdirectory, the program is stored in the bin / subdirectory, and the configuration file is stored in the etc / subdirectory.

[0078] Scenario embodiment three

[0079] In the exemplary embodiments of the present application, the cross-system running of the application is realized through the control program, and the control program has a special dynamic library file, in which the functions of execvp, execve, execv, execl, execlp, dlopen and the like are written. These functions have the same name functions in the system default library, and the purpose of rewriting these functions is to control the behavior of the functions as expected when the application calls these functions.

[0080] For the exec function family, these functions are used to start a child process to execute a new program, and the processing of these functions is similar. During the running of the application, if the command in the package is called, the rewritten function will automatically add the corresponding path under the application installation path to the front of the PATH (path) and LD_LIBRARY_PATH (dynamic library search path) environment variable, so that the dependencies called by the command in the package come from the package; if a command outside the package is called, the rewritten function will automatically remove the entries containing the application installation path in the PATH, LD_LIBRARY_PATH and LD_PRELOAD (preloaded dynamic library) environment variables, so that the command outside the package is not affected by the files in the package. The structure of the rewritten function is as follows:

[0081] Function name (parameter) {;

[0082] The dlsym function is used to obtain the address of the function with the same name in the system default library;

[0083] If the program to be executed is under the application installation directory{; ​

[0084] Add the bin, lib, etc. directory path under the application installation path to the front of the environment variable PATH, LD_LIBRARY_PATH;

[0085] };

[0086] Else{;

[0087] Remove the entry containing the application installation path from the environment variable PATH, LD_LIBRARY_PATH, LD_PRELOAD;

[0088] };

[0089] Execute the same name function in the system default library;

[0090] }。

[0091] For the dlopen function, the function is used to load dynamic library. In the application running process, if the dynamic library in the application package is to be loaded, the corresponding path under the application installation path is added to the front of LD_LIBRARY_PATH; if the dynamic library not in the package is to be loaded, all entries containing the installation path in LD_LIBRARY_PATH are removed. In this way, when the dynamic library is loaded, the dynamic library and other dynamic libraries dependent thereon can be correctly found. The rewritten dlopen function structure is as follows:

[0092] dlopen (parameters) {;

[0093] Use the dlsym function to obtain the address of the dlopen function in the system default library;

[0094] If the dynamic library to be loaded is found under the installation directory{;

[0095] Add the lib, etc. directory path under the application installation path to the front of the environment variable LD_LIBRARY_PATH;

[0096] };

[0097] Else{;

[0098] Remove the entry containing the application installation path from the environment variable LD_LIBRARY_PATH;

[0099] };

[0100] Execute the dlopen function in the system default library;

[0101] Restore the modified LD_LIBRARY_PATH environment variable;

[0102] }。

[0103] The application program is linked to the control program through a soft link. When a user runs the application program, the control program is actually run first. The control program sets the LD_PRELOAD environment variable value as the path of the special dynamic library file first, and then starts a sub-process to make the special dynamic library be loaded preferentially. At this time, the function in the special dynamic library is used preferentially to the same name function in the system default library, which is equivalent to hijacking the call to the same name function in the system. Then, the actual program to be executed is started in the sub-process by calling the rewritten execvp function. After that, during the running process of the application, if the application calls the execvp, execve and the like again, the rewritten same name function is actually executed. These rewritten functions will dynamically modify the settings described above. Such a processing mechanism finally enables the multi-command entry application to run correctly when calling itself and calling the system native command.

[0104] In the example embodiment of the present application, for the scenario that the application does not call other commands during the running process of the application, the processing flow of the control program is as shown in Figure 6 The flow includes the following steps:

[0105] Step S601, a user inputs a command to run an application.

[0106] Step S602, the control program sets LD_PRELAOD (preloading dynamic library).

[0107] Step S603, a sub-process is started to make the special dynamic library be loaded.

[0108] Step S604, a rewritten execvp function is called to execute a new program.

[0109] Step S605, the rewritten execvp adds the application installation directory in the environment variable PATH and LD_LIBRARY_PATH (dynamic library search path).

[0110] Step S606, the execvp function in the system default library is called to run the application.

[0111] In the example embodiment of the present application, for the scenario that one command entry of the multi-command entry application calls other commands of the application during the running process, the processing flow of the control program is as shown in Figure 7 Here, it is assumed that the application internally calls other commands through the functions in the exec function family. The flow includes the following steps:

[0112] Step S701, a user inputs a command to run an application.

[0113] Step S702, the control program sets LD_PRELAOD.

[0114] Step S703, the startup subprogram makes the special dynamic library loaded;

[0115] Step S704, the rewritten execvp function is called to execute the new program;

[0116] Step S705, the rewritten execvp adds the application installation directory in the environment variable PATH, LD_LIBRARY_PATH;

[0117] Step S706, the execvp function in the system default library is called to run the application;

[0118] Step S707, if the execvp function is called to run other commands in the application, the execvp function is hijacked and the rewritten execvp function is run;

[0119] It should be noted that the environment variable PATH, LD_LIBRARY_PATH already contains the application installation path and does not need to be processed;

[0120] Step S708, the execvp function in the system default library is called to run the application.

[0121] In the exemplary embodiments of the present application, if the system command is called when the application is running, the rewritten function deletes all entries containing the application installation path in PATH, LD_LIBRARY_PATH, LD_PRELOAD, and then continues to execute the same function in the system default library.

[0122] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program, and the computer program is configured to execute the steps in any of the method embodiments when running.

[0123] In an exemplary embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0124] The embodiments of the present application also provide an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor is configured to execute the computer program to execute the steps in any of the method embodiments.

[0125] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0126] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0127] Obviously, those skilled in the art should understand that the modules or steps of the present application described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0128] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A method for packaging an application, characterized in that: include: Installing a source system including the original basic operating and development environments of the packaged application in a packaging system using a package management tool, wherein the packaging system and the package management tool of the source system are the same, and the source system is the system on which the application is originally intended to run before being packaged; Compile the control program in the source system, set the dynamic link loader path of the control program to the placement path of the internal loader of the package after the package is installed, and store the control program in the packaging directory; Generate an application installation package based on the files in the packaging directory.

2. The method according to claim 1, characterized in that The process of installing the source system including the original basic operation and development environment of the packaged application in the packaging system through the package management tool includes: In the packaging system, by using the same package management tool and packaging configuration file as those of the source system, the source system including the original basic operation and development environment of the application is installed in a temporary directory; The packaging configuration file includes soft link information and a software package repository address. The soft link information is used to indicate a list of files that need to establish soft links, and the software package repository address is used to provide the software package and original operating environment included in the application.

3. The method according to claim 2, characterized in that Before compiling the control program in the source system, the method further includes: Extracting files in the software package from the source system, and collecting dependent libraries and basic libraries required for running the software package based on the files, wherein the basic libraries include library files related to the running of a dynamic link loader; Reset the path of the dynamic link loader in the executable and linkable format ELF file in the file, the basic library and the dependent library to an absolute path, wherein the absolute path points to the placement path of the package internal loader after the package is installed; Remove the runtime library paths of all the ELF files and store all the processed files in the packaging directory according to the original directory structure.

4. The method according to claim 3, characterized in that The step of collecting dependent libraries required for running the software package based on the file includes: The dependent libraries are collected by using the ldd command to list dynamic library dependencies for all dynamic link files in the software package, obtaining the shared libraries and paths that the dynamic links depend on, and using the ldd command on the shared libraries until all dependent libraries are found.

5. The method according to claim 3, characterized in that The generating of the application installation package according to the files in the packaging directory includes: generating the application installation package by generating the management program, metadata, and the files in the packaging directory.

6. The method according to claim 5, characterized in that in, The metadata includes at least one of the following: soft link information, length and start address of each area, application information, dependency information, provided function information, scripts to be executed before and after installation and uninstallation, and signature information.

7. The method according to claim 6, characterized in that in, The areas include: a hypervisor area, a metadata area, and an application data area.

8. The method according to claim 2, characterized in that The packaging configuration file also includes at least one of the following: Application name, used to indicate the name of the packaged application; The application version number is used to indicate the packaged version number of the application; Application description; A list of package names, used to indicate information about packaged objects; The pre- and post-installation scripts are used to customize the actions of the application when installing and uninstalling.

9. The method according to claim 1, characterized in that The method further comprises: When the application installation package is installed, the management program of the application installation package installs and deploys the files in the application installation package to a designated new directory, and creates a soft link to the root directory according to the soft link information in the application installation package.

10. The method according to claim 9, characterized in that The step of establishing a soft link to the root directory based on the soft link information in the application installation package includes at least one of the following: Unify the soft links of the executable files to point to the control program of this application; Point the soft link file to its original target; Point other files to the corresponding entity files in the installation directory.

11. The method according to claim 1, wherein The method further comprises: Upon receiving an instruction to run the application, the control program sets the value of the preloaded dynamic library environment variable to the path of the special dynamic library file; The special dynamic library is loaded preferentially by starting a child process, so that the execution function in the special dynamic library is called preferentially over the function with the same name in the system default library; The program to be actually executed is started in the child process by calling the rewritten execution function.

12. The method according to claim 11, characterized in that The execution function includes at least one of the following: an execution file path search function, a dynamic path modification function, a dynamic library path search function, a preloaded dynamic library environment variable function, and an execution system default library function with the same name.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 12 when executed by a processor.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 12 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Citation Information

Patent Citations

  • Domestic application cross-system migration method based on container template

    CN112379924A

  • Packing method of application dependent self-contained technology under linux system

    CN113986395A

  • Application packaging method and device, electronic equipment and storage medium

    CN117331571A

  • Secondary battery

    KR1020210129998A