Multi-type embedded real-time communication type toolkit compiling test method and storage card

Abstract

The application provides a multi-type embedded real-time communication type toolkit compilation test method and a storage card. The method detects the existence state of a core static library file in a toolkit directory and determines the current toolkit type; determines the compilation source file by matching the header file reference type of the test source code with the current toolkit type; generates a compilation link parameter set; completes the closed symbol link environment by performing transmission dependency completion on the basic symbol link environment; generates a test executable program by performing a compilation link operation and completes test verification; and the storage card provided by the application realizes the portability, standardization, high efficiency and reliability of the compilation test capability by encapsulating complex algorithms, adaptive logic and best practices through hardware encapsulation, thereby bringing revolutionary convenience and efficiency improvement to the test work of multi-type and multi-version embedded real-time communication toolkits.

Description

Technical Field

[0001] This application relates to the field of communication testing technology, and in particular to a compilation and testing method for a multi-type embedded real-time communication toolkit and a memory card. Background Technology

[0002] With the rapid development of Internet of Things (IoT) technology, embedded real-time communication (RTC) technology has been widely applied to terminal devices such as IP cameras, smart doorbells, video locks, and smart home devices. These devices typically require the integration of a software development kit (SDK) to achieve real-time communication functions such as audio and video capture, encoding / decoding, network transmission, and signaling interaction. Due to the fundamental differences in protocol stacks, interface definitions, and library dependencies between different communication standards (such as real-time communication via WiFi and wake-up control via 4G), the same product series often requires maintaining multiple types and versions of toolkit branches, resulting in exceptionally complex compilation and adaptation work during the testing and verification phase.

[0003] In existing technologies, compilation and testing schemes for embedded real-time communication toolkits can be mainly divided into three categories: The first category is the independent test project scheme, which establishes an independent test project for each toolkit version and type, avoiding cross-interference through completely isolated project spaces. However, this method results in a linear increase in the number of projects with version iterations, leading to extremely high maintenance costs, and version switching requires manual importing and exporting of a large number of configurations. The second category is the manual configuration switching scheme, which requires testers to manually modify the compilation configuration file (Makefile) and linker parameters, manually specifying the header file search path, library file list, and compilation macro definitions. This method is not only cumbersome to operate, but also prone to omissions or errors due to human negligence, leading to hidden compilation or linking errors. The third category is the script parameterization scheme, which receives some compilation parameters through preset scripts and automatically fills them into the compilation commands. Although this improves the degree of automation to a certain extent, the underlying compilation adaptation details (such as toolkit type identification, dynamic library version alignment, address sanitizer (ASAN) compilation strategy matching, etc.) still highly rely on manual presets and post-event investigation, and cannot be adaptively adjusted according to the actual state of the toolkit.

[0004] However, when faced with complex testing environments where multiple types and versions of toolkits coexist, the existing solutions lack automatic identification and arbitration capabilities when the toolkit directory contains both static libraries for wake-up calls and static libraries for real-time communication due to incomplete version switching or residual historical compilation artifacts. This can easily lead to compilation process interruptions. Furthermore, dynamic libraries, such as the secure transport layer protocol library, have nested shared object internal name version chains. Their runtime dependencies involve not only directly dependent first-level dynamic libraries but also multi-level transitive dependencies declared by required dependency fields. Existing solutions only handle first-level direct dependencies and cannot recursively resolve and complete transitive dependency chains, resulting in frequent file opening errors during program runtime. Summary of the Invention

[0005] This application provides a compilation and testing method and storage card for multiple types of embedded real-time communication toolkits, aiming to solve the technical problems of low reliability in compilation and testing when toolkit type switching and dynamic library linking occur because existing technologies cannot automatically identify toolkit types and arbitrate conflicts between coexisting dual libraries in scenarios where multiple types and versions of toolkits coexist, and cannot recursively parse and complete multi-level transitive dependency chains of dynamic libraries.

[0006] This application provides a method for compiling and testing multi-type embedded real-time communication toolkits, which includes the following steps: The existence status of at least one core static library file in the toolkit directory is detected, and the current toolkit type is determined based on the result of the existence status determination. Obtain the header file reference type of the test source code, and match the header file reference type with the current toolkit type to determine the source file to be compiled; Based on the current toolkit type and the header file information of the compiled source file, dynamically assemble compilation and linking parameters to generate a set of compilation and linking parameters; Based on the dynamic library files in the toolkit directory, a basic symbolic link environment is constructed, and transitive dependency completion is performed on the basic symbolic link environment based on runtime dependency requirements to obtain a closed symbolic link environment. Based on the source file, the complete set of compilation and linking parameters, and the closed symbolic linking environment, the compiler is triggered to perform compilation and linking operations, generate a test executable program, and complete test verification based on the test executable program.

[0007] This application provides a compilation and testing method and storage card for multi-type embedded real-time communication toolkits. The method automatically determines the current toolkit type by detecting the existence status of core static library files in the toolkit directory and based on the judgment result, avoiding type misjudgment caused by manual identification. It automatically adapts the test source code to the toolkit type by obtaining the header file reference types of the test source code and matching them with the current toolkit type, avoiding compilation errors caused by type mismatch. Based on the current toolkit type and the header file information of the compiled source file, it dynamically assembles compilation and linking parameters to generate a compilation and linking parameter set, achieving automated configuration of compilation parameters and avoiding... This approach eliminates omissions or misconfigurations caused by manual configuration. It constructs a basic symbolic link environment based on the dynamic library files in the toolkit directory, and completes transitive dependencies on this environment based on runtime dependency requirements to obtain a closed symbolic link environment. This achieves automatic closure of multi-level transitive dependency chains for dynamic libraries, avoiding transitive dependency breaks caused by handling only first-level direct dependencies. Finally, based on the compiled source files, the complete set of compilation and linking parameters, and the closed symbolic link environment, the compiler is triggered to perform compilation and linking operations to generate a test executable program and complete test verification. This achieves full-link automation of compilation testing in toolkit type switching and dynamic library linking scenarios, improving the reliability of compilation testing. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A schematic diagram of the overall architecture of an embodiment of a compilation and testing method for a multi-type embedded real-time communication toolkit provided in this application; Figure 2 A flowchart illustrating an embodiment of a compilation and testing method for a multi-type embedded real-time communication toolkit provided in this application; Figure 3 A flowchart illustrating the automatic identification of toolkit types and document arbitration provided in this application embodiment; Figure 4 A timing diagram of the automatic switching process for source port file compatibility provided in this application embodiment; Figure 5 Timing diagram of the two-dimensional automatic detection and injection mechanism for compilation options provided in the embodiments of this application; Figure 6 A timing diagram of the dynamic library internal name recursive resolution and symbolic link reconstruction process provided in the embodiments of this application; Figure 7 A comparison chart of key indicators of the test schemes of the present invention and the traditional technical solutions provided in the embodiments of this application.

[0010] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0013] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0014] This application provides a compilation and testing method for multiple types of embedded real-time communication toolkits, which involves the testing and verification of embedded real-time communication (RTC) toolkits. It is mainly used for the testing and verification of real-time communication toolkits on IoT devices such as network cameras (IPCs), smart doorbells, video locks, and smart home devices.

[0015] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the overall architecture of an embodiment of a compilation and testing method for a multi-type embedded real-time communication toolkit provided in this application. Figure 1 As shown, the core architecture of this invention is a four-layer adaptive pipeline: "S1 Automatic toolkit type identification and file arbitration; S2 Automatic source port file compatibility switching (including degradation); S3 Dynamic assembly of compilation and linking parameters in two dimensions; S4 Recursive resolution and link reconstruction of internal names of dynamic libraries." The essential difference from existing technologies lies in the fact that each layer has a built-in adaptive handling mechanism (8 types in total) for special abnormal scenarios, achieving a leap from "conventional single-path configuration" to "multi-path anomaly self-healing."

[0016] Figure 1The process includes standard processing steps and special scenario handling, including: Scenario 1 (arbitration of conflicts between coexisting libraries), Scenario 2 (automatic cleanup of residual files), Scenario 3 (automatic generation of stubs for friendly degradation), Scenario 4 (header file content fingerprint-based version awareness), Scenario 5 (dual-mode detection using address sterilizer), Scenario 6 (automatic injection of version macros), Scenario 7 (proactive cleanup of known error internal names), and Scenario 8 (recursive completion of transitive dependencies). The final output is a successfully compiled executable file or stub program, which automatically resumes compilation upon recovery.

[0017] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of a compilation and testing method for a multi-type embedded real-time communication toolkit provided in this application.

[0018] like Figure 2 As shown, the compilation and testing method for the multi-type embedded real-time communication toolkit includes steps S101 to S105.

[0019] S101. Detect the existence status of at least one core static library file in the toolkit directory, and determine the current toolkit type based on the determination result of the existence status.

[0020] This embodiment performs a full file traversal detection in the directory containing the detection toolkit to identify the existence status of core static library files in the directory, achieving automatic identification of toolkit type and file arbitration, and collecting the existence status of two types of static library files, including their presence, absence, and coexistence of multiple versions. The core static library files include libwakeupsdk.a (wake-up static library file) and librtcsdk.a (real-time communication static library file).

[0021] In existing testing solutions for embedded real-time communication toolkits, creating independent projects for each toolkit version leads to high maintenance costs, and manual modification of compilation parameters is prone to errors. When both types of static library files exist in the software development kit directory, traditional testing solutions cannot automatically identify the toolkit type or automatically determine library file priorities, relying solely on manual modification of the Makefile for switching. Manual operation is prone to omissions and errors in configuration. Some script parameterization solutions only achieve shallow parameter passing and cannot detect underlying static library conflicts, leading to compilation anomalies such as symbol redefinition and linking failures. Furthermore, cross-version file remnants can cause hidden cross-contamination compilation errors, and existing solutions lack automatic detection and cleanup mechanisms.

[0022] This embodiment uses wake-up control static library files and real-time communication static library files as the basis for type determination because the two types of toolkits have mutually exclusive inclusion characteristics in their core library files: wake-up control toolkits must contain wake-up control static library files, and real-time communication toolkits must contain real-time communication static library files. Zero-second type identification can be achieved through file existence detection, eliminating the need for manual review of version control documentation.

[0023] In one embodiment, when a wake-up static library file exists in the toolkit directory but a real-time communication static library file does not exist, the current toolkit type is determined to be wake-up control type; when the real-time communication static library file exists in the toolkit directory but the wake-up static library file does not exist, the current toolkit type is determined to be real-time communication type; when both the wake-up static library file and the real-time communication static library file exist simultaneously, a conflict arbitration mechanism is triggered, a conflict coexistence state is marked, and the current toolkit type is determined to be wake-up control type.

[0024] Specifically, the wake-up control type toolkit in fourth-generation mobile communication uses a direct communication mechanism of Transmission Control Protocol / User Datagram Protocol (TCP / UDP) to complete the signaling and media stream transmission between the device and the server. Its communication protocol stack is built into the wake-up static library file itself, without relying on the WebSocket protocol stack provided by the network socket library (libwebsockets.a, WebSocket protocol support library). Therefore, when a file system scan confirms the existence of the wake-up static library file (libwakeupsdk.a, the 4G wake-up core static library archive file) in the toolkit directory, and the absence of the real-time communication static library file (librtcsdk.a, the WiFi RTC core static library archive file), it can be determined that the current toolkit type is the wake-up control type (i.e., the fourth-generation mobile communication wake-up SDK type), and this determination result is written to the type status register as a benchmark condition for subsequent source code adaptation and parameter assembly.

[0025] The real-time communication toolkit in wireless LANs uses the WebSocket protocol to establish and maintain signaling channels, and relies on the WebSocket library file (libwebsockets.a) to complete the encoding and decoding of WebSocket frames and long connection management. Therefore, if a file system scan confirms the presence of the real-time communication static library file (librtcsdk.a) in the toolkit directory, and the absence of the wake-up static library file (libwakeupsdk.a), the toolkit type can be determined to be real-time communication (i.e., wireless LAN real-time communication SDK type). The WebSocket library file will then be automatically added as a dependency during the subsequent linker library assembly stage, eliminating the need for testers to manually consult the toolkit documentation or modify compilation configuration files.

[0026] When the platform detects the simultaneous presence of both the wake-up static library file (libwakeupsdk.a) and the real-time communication static library file (librtcsdk.a) in the toolkit directory, this is considered an abnormal mixed state. This is typically caused by remnants from cross-version toolkit upgrades, the merging and deployment of multiple types of toolkits, or the failure to clean up historical compilation artifacts. Current technology cannot automatically distinguish between master and slave libraries in this situation, directly triggering a fatal "multiple definition" error during the linking phase.

[0027] In this embodiment, when both the wake-up static library file and the real-time communication static library file coexist, a conflict arbitration mechanism is triggered. This conflict arbitration mechanism specifically includes: marking conflicting coexistence states; executing a wake-up control type priority strategy to determine that the current toolkit type is wake-up control type; injecting the linker with multiple definition options; and cleaning up residual cross-linked files.

[0028] Specifically, the conflict coexistence flag is used to identify the current special arbitration state during the subsequent compilation and linking parameter assembly stage. This allows for the coordinated triggering of residual file cleanup and linker flag injection, ensuring the consistency of decisions across the entire adaptive pipeline in abnormal scenarios. Specifically, a dual-library coexistence flag is set in the platform's internal status register to record that the current compilation environment is in a non-standard mixed state. This flag is then passed to the subsequent two-dimensional dynamic assembly step of compilation and linking parameters, serving as a trigger condition for injecting special linker options.

[0029] The wake-up control type priority strategy addresses the challenge of automatically handling symbol conflicts when two libraries coexist in existing technologies. Specifically, the wake-up static library file (libwakeupsdk.a) is designated as the master library, while the real-time communication static library file (librtcsdk.a) is relegated to a slave library. This priority strategy is based on the fact that in embedded real-time communication (RTC) test matrices, the symbol set of the wake-up control type toolkit is typically a subset or compatibility set of the real-time communication toolkit, and the wake-up control type has higher business priority in IoT device testing scenarios. Using the wake-up static library file as the master library maximizes the stability of symbol resolution during the linking phase.

[0030] The `--allow-multiple-definition` option in the linker's parameter list is used to automatically inject the `-Wl,--allow-multiple-definition` linker flag. This flag is a GNU Linker-specific option. Its technical function is to instruct the linker not to exit with an error when encountering symbols with the same name during the global symbol table resolution phase (such as basic network interface symbols shared by two types of toolkits), but instead to allow duplicate definitions and select the first encountered symbol instance to complete the linking. This operation directly solves the linking failure problem caused by symbol table overlap when two libraries coexist, achieving a self-healing mechanism from "hard errors" to "automatic arbitration."

[0031] Cleaning up residual cross-referenced files refers to deleting residual cross-referenced files that conflict with the wake-up control main library type according to a preset cleanup list. Specifically, this includes: the real-time communication static library file (librtcsdk.a), the network socket library file (libwebsockets.a), the real-time communication definition header file (rtc_defines.h), and the real-time communication development header file (rtc_fordev.h). The technical significance of this cleanup operation is to prevent residual files from being incorrectly included by the compiler during subsequent preprocessing and compilation stages, thus avoiding hidden cross-type interface definition conflicts. For example, if the real-time communication definition header file (rtc_defines.h) remains in the wake-up control toolkit directory, the video call-specific structures defined within it will cause namespace pollution with the simplified header file of the wake-up control toolkit, leading to numerous difficult-to-diagnose compilation errors in the test source code when type mismatches occur.

[0032] In this embodiment, when two types of core library files coexist in the toolkit directory due to incomplete version switching or human error, direct linking will trigger a multi-definition error in the linker. This embodiment addresses this by forcibly specifying the wake-up control type as the primary library and injecting a multi-definition-allowing linker flag, ensuring the compilation and linking process can continue instead of being directly interrupted, thus achieving a transition from a "hard error" to "soft adaptation." Simultaneously, the linker is automatically injected with -Wl,--allow-multiple-definition (the multi-definition-allowing linker flag) to eliminate potential multi-definition errors during the linking stage and clean up incompatible cross-linked residual files.

[0033] In one embodiment, when neither the wake-up static library file nor the real-time communication static library file exists, the path string to be matched in the toolkit directory is extracted; if the path string to be matched contains at least one item from the wake-up control type keyword set, the current toolkit type is determined to be wake-up control type; if the path string to be matched contains at least one item from the real-time communication type keyword set, the current toolkit type is determined to be real-time communication type; if the path string to be matched contains keywords from both the wake-up control type keyword set and the real-time communication type keyword set, the current toolkit type is determined to be wake-up control type.

[0034] If the platform confirms through file system scanning that neither the wake-up static library file (libwakeupsdk.a) nor the real-time communication static library file (librtcsdk.a) exists in the toolkit directory, the current state is determined to be a missing core library file state. This may be caused by the following reasons: the toolkit has not yet been compiled and built, the core library file naming is not standard, or the toolkit only contains header files and dynamic libraries and has not generated static library archive files.

[0035] In existing embedded real-time communication toolkit testing solutions, testers need to manually identify the toolkit type and manually modify compilation and linking parameters, which is costly to maintain and prone to errors. In the pre-integration stage, before the core static library files have been released to the toolkit directory, or in scenarios where abnormal toolkit directory structure causes file detection to fail, existing solutions lack effective auxiliary judgment methods and usually directly terminate the test by reporting an error, interrupting the compilation process and causing test blockage.

[0036] This embodiment employs a fallback and supplement mechanism, using a path string keyword matching fallback strategy to maintain the continuity of the compilation and testing process. The path string keyword matching fallback strategy is used to address scenarios where core static library files have not yet been released to the toolkit directory during the pre-integration phase, or where abnormal toolkit directory structures cause file detection failures. Type identifier keywords in the directory path are used for auxiliary determination to ensure full path coverage of the type identification logic.

[0037] Specifically, the platform extracts the path string to be matched from the toolkit directory. This path string is either the absolute path of the toolkit's root directory or a directory name string. For example, if the toolkit is deployed under the path ` / opt / sdk / wifi_rtc_v6.0 / ` or ` / home / user / 4g_wakeup_sdk / `, the complete path string is extracted as the object to be matched. This extraction operation is implemented through standard filesystem calls (such as the `pwd` or `getcwd` system calls), requiring no parsing of any binary files or configuration files, thus exhibiting zero computational overhead.

[0038] The process involves performing case-insensitive substring matching on the path string to be matched, retrieving preset type identifier keywords. The case-insensitive substring matching is used to ensure compatibility with toolkit directory paths using different naming conventions, preventing matching failures due to case differences and improving the robustness of the judgment logic.

[0039] If the path string to be matched contains at least one item from the wake-up control type keyword set, then the current toolkit type is determined to be wake-up control type. The wake-up control type keyword set includes, but is not limited to, identifiers such as "4g", "wakeup", "wake-up", and "fourth generation". This keyword set is constructed based on the engineering practices and version management specifications of embedded real-time communication (RTC) toolkits, where toolkit directory names typically include type identifiers to distinguish different communication standards. For example, the directory name 4g_wakeup_sdk_v2.3.0 explicitly indicates that this toolkit is a fourth-generation mobile communication wake-up control type.

[0040] Specifically, the path string to be matched is subjected to regular expression matching or substring inclusion detection against a preset set of wake-up control type keywords. When the path string to be matched contains at least one item from the wake-up control type keyword set, the current toolkit type is determined to be a wake-up control type (i.e., the fourth-generation mobile communication wake-up SDK type). This determination result is written to the type status register, and in the subsequent compilation and linking parameter assembly stage, the list of linked libraries is assembled according to the standard dependency rules of the wake-up control type (excluding the network socket library file libwebsockets.a), ensuring that the compilation process continues to execute based on the inferred type.

[0041] If the path string to be matched contains at least one item from the set of keywords for real-time communication types, then the current toolkit type is determined to be real-time communication type. The set of keywords for real-time communication types includes, but is not limited to, identifiers such as "wifi", "rtc", "wireless", "real-time communication", and "wireless LAN". For example, the directory name wifi_rtc_sdk_v5.0 or wireless_rtcp explicitly indicates that the toolkit is a real-time communication type for wireless LAN.

[0042] Specifically, the path string to be matched is subjected to regular expression matching or substring inclusion detection against a preset set of real-time communication type keywords. When the path string to be matched contains at least one item from the set of real-time communication type keywords, the platform determines that the current toolkit type is a real-time communication type (i.e., a wireless LAN real-time communication SDK type). This determination result is also written to the type status register, and the network socket library file (libwebsockets.a) is automatically added as a necessary dependency during the subsequent compilation and linking parameter assembly stage, while the header file compatibility switching rules corresponding to the real-time communication type are enabled.

[0043] If the path string to be matched contains keywords from both the wake-up control type keyword set and the real-time communication type keyword set, then the current toolkit type is determined to be the wake-up control type, and the wake-up control type is taken as the priority judgment result.

[0044] Specifically, when the path string to be matched contains two types of keywords simultaneously (e.g., the directory name is 4g_wifi_hybrid_sdk or unified_wakeup_rtc), path-level conflict arbitration is triggered, determining that the current toolkit type is wake-up control type. The arbitration logic of this path-level conflict arbitration is an extension and unification of the dual-library coexistence conflict arbitration mechanism: a wake-up control priority strategy is executed at both the file system level (core library file coexistence) and the path naming level (type keyword coexistence). Its technical basis lies in the fact that the symbol set and interface definition of wake-up control type toolkits are usually a subset or compatible set of real-time communication toolkits. Using wake-up control type as a conservative inference can minimize the risk of undefined symbols due to type misjudgment during subsequent compilation stages.

[0045] Simultaneously, in this situation, a prompt message is output to the standard error output port, informing testers that the current toolkit type is a path-inference-based wake-up control type, and suggesting checking the naming conventions of the toolkit directory or supplementing core static library files to improve the accuracy of the judgment. This prompt message does not interrupt the compilation and testing process, achieving an exception self-healing degradation from "fatal error" to "continue with prompt".

[0046] Through the aforementioned path string keyword matching fallback mechanism, even in the extreme abnormal scenario where the core static library files are "completely missing," the platform can still extract type clues from the semantics of directory naming to complete the fallback determination of the toolkit type, ensuring that the multi-type embedded real-time communication toolkit compilation and testing platform has continuous service capabilities in edge scenarios where the toolkit deployment is incomplete or non-standardized.

[0047] In one specific embodiment, please refer to Figure 3 , Figure 3 This diagram illustrates the automatic identification of toolkit types and document arbitration process provided in this application embodiment. Figure 3 As shown, the toolkit directory file list is first read, the existence status of the core static library files is detected, and the current toolkit type is determined based on the determination result of the existence status.

[0048] First, determine whether the wake-up static library file (libwakesdk.a, i.e. libwakeupsdk.a, the archive file of the core static library for fourth-generation mobile communication wake-up) exists.

[0049] If the wake-up static library file exists, the current toolkit type is determined to be the fourth-generation mobile communication wake-up toolkit main library, with libwakesdk.a as the main library, and the network socket library file (libwebsockets.a) is excluded. Then, it is further determined whether the real-time communication static library file (librtcsdk.a) also exists: if the real-time communication static library file does not exist, the normal fourth-generation mobile communication mode is entered, and compilation is performed directly; if the real-time communication static library file exists, it is marked as a conflict coexistence state, the fourth-generation mobile communication priority strategy is executed, and the linker's allow-multiple-definition option is injected, entering the conflict arbitration mode.

[0050] If the wake-up static library file does not exist, the system further determines whether the real-time communication static library file (librtcsdk.a) exists. If the real-time communication static library file exists, it is determined to be the main library of the wireless LAN real-time communication toolkit, with librtcsdk.a as the main library and the network socket library file (libwebsockets.a) attached. If neither of them exists, the system falls back to matching the execution path string (containing keywords such as "4g" / "wakeup" mapped to the fourth-generation mobile communication wake-up type).

[0051] Based on the above judgment results, the following link library list is assembled: libwebsockets is excluded for the fourth-generation mobile communication mode; libwebsockets is added for the wireless LAN real-time communication mode; and the allow-multiple-definition linker option is added for the conflict mode. Simultaneously, the following additional operations are performed: residual files from the wireless LAN real-time communication library are automatically cleaned up in the fourth-generation mobile communication toolkit directory, including the real-time communication static library file (librtcsdk.a), the network socket library file (libwebsockets.a), the real-time communication definition header file (rtc_defines.h), and the real-time communication development header file (rtc_fordev.h).

[0052] Please refer to Figure 3 , Figure 3 This diagram illustrates the automatic identification of toolkit types and document arbitration process provided in this application embodiment. Figure 3 As shown, the toolkit directory file list is first read, the existence status of the core static library files is detected, and the current toolkit type is determined based on the determination result of the existence status.

[0053] First, determine whether the wake-up static library file (libwakesdk.a, i.e. libwakeupsdk.a, the archive file of the core static library for fourth-generation mobile communication wake-up) exists.

[0054] If the wake-up static library file exists, the current toolkit type is determined to be the fourth-generation mobile communication wake-up toolkit main library, with libwakesdk.a as the main library, and the network socket library file (libwebsockets.a) is excluded. Then, it is further determined whether the real-time communication static library file (librtcsdk.a) also exists: if the real-time communication static library file does not exist, the normal fourth-generation mobile communication mode is entered, and compilation is performed directly; if the real-time communication static library file exists, it is marked as a conflict coexistence state, the fourth-generation mobile communication priority strategy is executed, and the linker's allow-multiple-definition option is injected, entering the conflict arbitration mode.

[0055] If the wake-up static library file does not exist, the system further determines whether the real-time communication static library file (librtcsdk.a) exists. If the real-time communication static library file exists, it is determined to be the main library of the wireless LAN real-time communication toolkit, with librtcsdk.a as the main library and the network socket library file (libwebsockets.a) attached. If neither of them exists, the system falls back to matching the execution path string (containing keywords such as "4g" / "wakeup" mapped to the fourth-generation mobile communication wake-up type).

[0056] Based on the above judgment results, the following link library list is assembled: libwebsockets is excluded for the fourth-generation mobile communication mode; libwebsockets is added for the wireless LAN real-time communication mode; and the allow-multiple-definition linker option is added for the conflict mode. Simultaneously, the following additional operations are performed: residual files from the wireless LAN real-time communication library are automatically cleaned up in the fourth-generation mobile communication toolkit directory, including the real-time communication static library file (librtcsdk.a), the network socket library file (libwebsockets.a), the real-time communication definition header file (rtc_defines.h), and the real-time communication development header file (rtc_fordev.h).

[0057] S102. Obtain the header file reference type of the test source code, and match the header file reference type with the current toolkit type to determine the source file to be compiled.

[0058] In existing embedded real-time communication toolkit testing solutions, testers need to manually identify the compatibility between the test source code and the current toolkit type. When an incompatible test module is incorrectly selected, the compiler directly outputs numerous compilation errors, requiring testers to spend a significant amount of time troubleshooting the root cause. Furthermore, application programming interface (API) structure fields differ between different toolkit versions; existing solutions rely on manually consulting version documentation and defining compiler macros, failing to automatically detect changes in header file APIs. When backup source files are missing, existing solutions lack a user-friendly degradation mechanism, directly interrupting the compilation process.

[0059] This application embodiment achieves automatic matching and compatibility switching between the source code and the current toolkit type by detecting the header file reference type of the test source code. Please refer to... Figure 4 , Figure 4 This is a timing diagram illustrating the automatic switching process for source port file compatibility provided in an embodiment of this application. (See diagram below.) Figure 4As shown, this sequence diagram involves three interactive objects: the test module (source.cpp), the test platform (build_helper.sh), and the toolkit directory (SDK and compiler). The timing process includes: 1. The test module sends the test source code to the test platform (selecting the test module); 2. The test platform queries the toolkit directory for the current toolkit type. The toolkit directory returns the wake-up control type or real-time communication type. At the same time, the test platform uses grep to detect the #include header file reference type (rtc_defines.h or wakeup_defines.h) in the test source code; 3. The test platform performs compatibility matching: if the detected header file reference type does not match the current toolkit type (e.g., rtc_defines.h is detected and the current type is wake-up control, or wakeup_defines.h is detected and the current type is real-time communication), it checks whether there is a corresponding backup source file (source_4g.cpp or source_wifi.cpp) in the same directory. If it exists, it automatically switches to the backup source file. If it does not exist, it triggers the generation of a stub program and outputs user boot information. If the header file reference type matches the current toolkit type, the original test source code is retained; 4. The test platform submits the final compiled source files (switched / stub / original) to the compiler for compilation and linking; 5. After the compiler completes the compilation and linking, it returns the executable file to the test platform.

[0060] Generally, test source code distinguishes the applicable toolkit type by including different definition header files. The real-time communication definition header file corresponds to the real-time communication video call application interface, and the wake-up definition header file corresponds to the wake-up control application interface.

[0061] Specifically, the preprocessor directives section at the top of the test source code file is scanned using a text search tool (grep, a global regular expression search tool) to extract the names of header files referenced by #include (file inclusion directives).

[0062] If the real-time communication definition header file (rtc_defines.h) is referenced, then the header file reference type is determined to be real-time communication. The real-time communication definition header file (rtc_defines.h) is a dedicated interface definition file for the WiFi RTCSDK (Wireless Local Area Network Real-Time Communication Toolkit), containing application programming interface (API) structures, enumeration constants, and function prototype declarations related to video calls. The inclusion of this header file in the test source code indicates that the test module relies on the video call capabilities of the real-time communication toolkit.

[0063] If the wakeup definition header file (wakeup_defines.h) is referenced, then the header file reference type is determined to be wakeup control type. The wakeup definition header file (wakeup_defines.h) is a dedicated interface definition file for the 4G WakeUp SDK, containing application programming interface definitions related to device wakeup control and low-power signaling interaction. The inclusion of this header file in the test source code indicates that the test module relies on the remote wakeup capability of the wakeup control SDK.

[0064] By automatically detecting header file references at the top of the source code, testers are no longer required to manually specify or remember the applicable types for each test module, thus avoiding human error in selection.

[0065] The extracted header file reference types are compared with the current toolkit types for compatibility verification. The essence of this compatibility verification is to verify whether the toolkit interfaces that the test source code depends on are consistent with the toolkit types actually deployed in the current compilation environment.

[0066] In one embodiment, when the header file reference type successfully matches the current toolkit type, the test source code is determined as the compilation source file; when the header file reference type fails to match the current toolkit type, the backup source file corresponding to the current toolkit type is switched as the compilation source file; when the backup source file does not exist, a compilable alternative program is generated as the compilation source file, wherein the alternative program outputs user boot information when it runs.

[0067] Specifically, the header file reference type is matched with the current toolkit type. When the header file reference type matches successfully with the current toolkit type, the platform directly uses the test source code as the compilation source file. For example, the current toolkit type is a wireless LAN real-time communication type, and the test source code references rtc_defines.h; or the current toolkit type is a wake-up control type, and the test source code references wakeup_defines.h. In this case, the test source code is fully compatible with the toolkit interface, the platform does not perform any file replacements, and directly sends the original test source code into the subsequent compilation and linking parameter assembly steps.

[0068] When the header file reference type fails to match the current toolkit type (for example, the current toolkit type is wake-up control, but the test source code references rtc_defines.h; or the current toolkit type is wireless LAN real-time communication, but the test source code references wakeup_defines.h), the automatic switching mechanism for backup source files is triggered, and the source code switching operation is performed.

[0069] The automatic backup source file switching mechanism addresses compatibility issues when the test source code doesn't match the current toolkit type. When a tester mistakenly selects a test module incompatible with the current toolkit type, the platform automatically finds a matching backup source file in the same directory and replaces it, achieving adaptive switching at the source code level, eliminating the need for manual source code searches or modifications.

[0070] Specifically, the source code switching operation includes: If the test source code references rtc_defines.h (the real-time communication definition header file) and does not match the current wake-up control type, the system searches for and switches to the Wi-Fi source file (source_wifi.cpp) in the same directory. This backup source file is a pre-written test implementation compatible with the Wi-Fi real-time communication toolkit interface, and its function signatures are consistent with the original test source code, ensuring the continuity of symbol resolution during the compilation and linking stages. If the test source code references wakeup_defines.h (the wake-up definition header file) and does not match the current real-time communication type, the system searches for and switches to the fourth-generation mobile communication source file (source_4g.cpp) in the same directory. This backup source file is a pre-written test implementation compatible with the wake-up control toolkit interface.

[0071] In a test platform where multiple toolkits coexist, the same test logic may need to call different application programming interfaces (APIs) for different communication standards (real-time wireless LAN communication / wake-up 4G). This application's embodiment utilizes an automatic switching mechanism with a backup source file. By pre-setting a backup source file with the same name, it automatically routes to the source code implementation matching the type without modifying the tester's original code, achieving "one set of test logic, automatic adaptation to multiple types".

[0072] When the test source code is detected to be incompatible with the current toolkit type and there is no corresponding backup source file in the same directory, the platform does not directly output a compilation error. Instead, it triggers a friendly degradation mechanism that automatically generates a stub to resolve the compilation interruption problem when the backup source file is missing.

[0073] Existing technologies directly output a large number of compilation error stacks when there is a type mismatch and the backup source file is not available, making it difficult for testers to quickly locate the root cause. This application's embodiment automatically generates a compileable and runnable stub program, converting "hard errors" into "soft bootstrapping." The stub program outputs clear switching prompts during runtime, enabling testers to directly understand the cause and take the correct switching action, reducing troubleshooting time.

[0074] In one embodiment, the friendly degradation mechanism of automatically generating stubs is a self-healing process for special abnormal scenarios, which specifically includes generating a minimal compilable alternative program and compiling and running to output boot information.

[0075] Specifically, generating a minimal compilable alternative program means that when a mismatch is detected between the test source code and the current toolkit type, and no corresponding backup source file exists in the same directory, a minimal C++ (a general-purpose programming language) source code is automatically generated in memory. This source code includes a standard main function entry point and necessary header files. The main function body embeds a user-defined guidance string, such as: "This test requires a wireless LAN real-time communication toolkit. Please press 's' in the main menu to switch the toolkit version to the wireless LAN type and try again." This alternative program is syntactically valid and can pass the compiler's syntax analysis and semantic checks.

[0076] The compilation and runtime output boot information refers to the user-defined boot information printed on the standard output port (stdout, standard output) or standard error output port (stderr, standard error) after the alternative program is compiled and linked to generate the test executable program. Testers can intuitively understand the root cause of the type mismatch and the switching instruction without having to read lengthy compiler error stack traces.

[0077] The friendly degradation mechanism can transform the time-consuming process of type mismatch, numerous compilation errors, and manual log checking in existing technologies into a self-healing process based on type mismatch, automatic stubs, and clear boot information. Testers do not need extensive compilation and debugging experience, nor do they need to manually modify source code or compilation configurations. They only need to switch toolkit types according to the boot information to resume testing, achieving anomaly self-healing degradation from "hard errors" to "soft boot".

[0078] The version number string declared in the toolkit header file may differ from the actual code due to human annotation errors, outdated documentation, or branch merge conflicts. However, enumeration definitions and function signatures are objective facts determined by the compiler. Therefore, a content fingerprinting mechanism is triggered simultaneously with the compilation source files. This mechanism addresses the issue of application interface version unawareness. Different toolkit versions may have differences in interface structure fields, and version number markings may contain errors, but enumeration definitions in the code are objective facts determined by the compiler. By detecting specific enumeration definitions in the header file as content fingerprints, the application interface version characteristics of the current toolkit can be automatically detected without relying on an external version configuration table, providing a basis for subsequent automatic injection of version macros.

[0079] Specifically, the content fingerprint of the toolkit header file is extracted, without relying on external version configuration tables or release notes, and the application interface version is directly perceived through objective code facts.

[0080] When the definition of ESdpCompressionMode (Session Description Protocol compression mode enumeration) is detected in the header file, the version 6.0 fingerprint is extracted. This enumeration is a significant new type in the WLAN Real-Time Communication Toolkit V6.0, used to control the compression encoding mode of the Session Description Protocol (SDP). Its existence indicates that the current toolkit supports fine-grained media negotiation capabilities, and accordingly, the corresponding version 1 macro definition is injected in subsequent steps.

[0081] When the definition of WakeUpExitMode (wake-up exit mode enumeration) is detected in the header file, the new version of the wake-up control fingerprint is extracted. This enumeration is a hallmark type of the new version of the fourth-generation mobile communication wake-up toolkit, used to define various modes in which the device exits from the wake-up state. Its existence indicates that the current wake-up control toolkit has enhanced state machine management capabilities, and accordingly, the corresponding second-version macro definition is injected in subsequent steps.

[0082] This embodiment achieves fully automatic adaptation of test source code and toolkit types through the above-mentioned header file reference type detection, automatic switching of backup source files, friendly degradation of stub programs, and content fingerprint extraction, and can complete source code routing and version awareness without manual intervention.

[0083] S103. Based on the current toolkit type and the header file information of the compiled source file, dynamically assemble the compilation and linking parameters to generate a compilation and linking parameter set.

[0084] In existing embedded real-time communication toolkit testing solutions, compilation and linking parameters rely on manual configuration, which has significant shortcomings in testing environments with multiple types and versions. Regarding the address sanitizer compilation strategy, inconsistencies exist between different versions within the same toolkit family: all versions of wake-up control toolkits compile with address sanitization, while some versions of real-time communication toolkits enable address sanitization while others do not. Existing solutions cannot automatically determine whether the current toolkit requires address sanitization, leading to linking errors due to mismatched compilation options. Regarding version macro definitions, application interface structure fields differ between toolkit versions. Existing solutions rely on manual definition of compilation macros after consulting version documentation, failing to automatically detect changes in header file application interfaces, resulting in a high rate of configuration omissions, and potential errors in version number marking, even though enumeration definitions in the code are objective facts determined by the compiler.

[0085] In this embodiment, based on the current toolkit type determination result and the compiled source files and their header file information, a two-dimensional dynamic assembly of compilation and linking parameters is performed. This two-dimensional dynamic assembly refers to the parallel execution of parameter assembly from two independent dimensions: address sanitizer detection and version macro injection. It includes the address sanitizer (ASAN, AddressSanitizer) compilation option dimension and the version macro compilation option dimension. Based on the differences in toolkit types and header file content fingerprints, an adapted set of compilation and linking parameters is automatically generated as the complete input for subsequent compiler compilation and linking operations.

[0086] Please refer to Figure 5 , Figure 5 A timing diagram of the two-dimensional automatic detection and injection mechanism for compilation options provided in the embodiments of this application. For example... Figure 5 As shown, this sequence diagram involves three interacting objects: the toolkit directory (libraries / header files), the test platform (build_helper.sh), and the compiler (gcc / g++).

[0087] The timing process includes: 1. The test platform obtains the toolkit type (wake-up control type / real-time communication type); 2. The test platform performs address sanitizer (ASAN) detection, including 2a. If the toolkit type is wake-up control type, the address sanitizer compilation option (-fsanitize=address) is directly injected, and 2b. If the toolkit type is real-time communication type, the symbol table of the real-time communication static library file is scanned using the nm command to detect the existence of the address sanitizer prefix symbol (_asan), and the decision is made whether to inject the address sanitizer compilation option based on the detection result; 3. The test platform performs version macro detection by scanning the content fingerprint of the header file (such as the ESdpCompressionMode enumeration) using grep, and injecting the corresponding version macro (such as -DRTC_SDK_VER_899) based on the detection result; 4. The test platform submits the assembled compilation and linking parameter set to the compiler; 5. The compiler performs compilation and linking based on the parameter set and returns the executable file.

[0088] like Figure 5 As shown, address sterilizer detection and version macro injection are two independent dimensions that together constitute a complete set of compilation and linking parameters, covering the dual needs of runtime detection and compile-time adaptation, and realizing the leap from manual item-by-item configuration to multi-dimensional automatic assembly.

[0089] To address the issue of inconsistent address sanitizer compilation strategies, the address sanitizer compilation option dimension provides a dual-mode detection mechanism to automatically determine whether the current toolkit needs to add the address sanitizer compilation option to the compilation and linking parameter set.

[0090] In one embodiment, a list of link libraries is assembled based on the current toolkit type, and the list of link libraries is added to the compilation and linking parameter set; an address sanitizer compilation option detection is performed, and the toolkit directory is detected to obtain a directory detection result; if the directory detection result indicates that a wake-up static library file exists in the toolkit directory, then the current toolkit is determined to be of the wake-up control type, and the address sanitizer compilation option is added to the compilation and linking parameter set; if the result indicates that a real-time communication static library file exists in the toolkit directory, then the symbol table of the real-time communication static library file is scanned, and when an address sanitizer prefix symbol is detected in the symbol table, the address sanitizer compilation option is added to the compilation and linking parameter set.

[0091] Specifically, based on the current toolkit type, a library link list is automatically generated and added to the compilation and linking parameter set. This library link list provides the linker with the library dependency information to be resolved during the compilation and linking phase, directly determining whether the final executable program can correctly complete symbol resolution and library dependency binding.

[0092] The wake-up control toolkit uses a direct communication mechanism via Transmission Control Protocol / User Datagram Protocol (TCP / UDP), eliminating the need for the WebSocket protocol stack provided by the network socket library (libwebsockets.a, the WebSocket protocol support library). Incorrect linking to this library will introduce redundant symbols and increase the binary size. The signaling channel of the real-time communication toolkit is built based on the WebSocket protocol and must use the network socket library for protocol frame encoding and decoding. Missing this dependency will result in an "Undefined Reference" (symbol unresolved) error during the linking phase.

[0093] Therefore, the specific assembly rules for the library list are as follows: When the current toolkit type is wake-up control, the library list uses the wake-up static library file (libwakeupsdk.a) as the main library and excludes the network socket library file (libwebsockets.a). When the current toolkit type is real-time communication, the library list uses the real-time communication static library file (librtcsdk.a) as the main library and adds the network socket library file (libwebsockets.a) as a necessary dependency.

[0094] Specifically, the code performs an address sanitizer (ASAN) compilation option check, scanning the toolkit directory for file existence and symbol table analysis to obtain directory detection results. This check addresses the inconsistency in address sanitizer compilation strategies across different versions of the same toolkit family, automatically preventing linking errors caused by mismatched compilation options. Specifically, all versions of the fourth-generation mobile communication wake-up toolkit are compiled with address sanitization enabled, while some versions of the wireless LAN real-time communication toolkit enable address sanitizer while others do not.

[0095] To address the issue of inconsistent address sanitizer compilation strategies, a dual-mode address sanitizer detection mechanism is implemented to resolve linking errors caused by inconsistencies in address sanitizer compilation strategies across different versions of the same toolkit family. This dual-mode mechanism employs both file type determination and symbol table scanning methods.

[0096] The algorithm prioritizes file type determination; if the static library file is missing, it then performs a symbol table scan. By executing file type determination and symbol table scanning sequentially according to priority, it ensures that address sanitization compilation options for different toolkit types and versions are correctly identified, achieving zero omissions.

[0097] The file type determination method directly determines the presence of the wake-up static library file without parsing binary content, resulting in high efficiency. It is suitable for wake-up control type toolkits with a unified compilation strategy that does not change with version.

[0098] Specifically, during the file type detection process, if a wake-up static library file exists in the toolkit directory, the current toolkit is determined to be a wake-up control type, and the address sanitization compilation option is added to the compilation and linking parameter set. This method relies on file existence for determination, without needing to parse binary content, and is suitable for wake-up control type toolkits with a unified compilation strategy that does not change with version.

[0099] When directory checks indicate that the wake-up static library file does not exist in the toolkit directory, but the real-time communication static library file (librtcsdk.a) does exist, a symbol table scan is performed as a downgrade detection method. The symbol table scan method accurately identifies whether the toolkit version was compiled using address sanitization by detecting the address sanitization prefix symbols in the symbol table of the real-time communication static library file. Because the compilation strategies of different versions of real-time communication toolkits are inconsistent, it is impossible to directly determine this based on file existence alone; therefore, objective evidence must be obtained through symbol table scanning to avoid incorrectly injecting compilation options into versions that do not enable address sanitization, leading to linking failures.

[0100] Specifically, the symbol table of the real-time communication static library file is scanned using a symbol table viewing tool (nm, Symbol Table Display Tool). The command is executed: nm “$RTC_SDK_DIR / librtcsdk.a” 2> / dev / null | grep -q “__asan_”, which checks whether the address sanitization (__asan_) prefix symbol exists in the symbol table.

[0101] The address sanitization (__asan_) prefix symbols (such as __asan_init, __asan_report_load1, __asan_register_globals, etc.) are runtime function call remnants injected into the object files of each compilation unit by the address sanitizer during the compilation phase. As a memory error detection tool, the address sanitizer modifies the code generation logic of the compilation unit when enabled, inserting runtime checking code to detect errors such as stack buffer overflows, heap buffer overflows, and misuse of freed memory. These inserted function calls form global symbols with the __asan_ prefix in the object files and are retained in the symbol table of the static library file during static library archiving.

[0102] Therefore, if the symbol table scan hits the address sanitization prefix symbol, it can be determined that the static library file was compiled using the address sanitizer, and the address sanitization compilation option is added to the compilation and linking parameter set accordingly. If the symbol table scan does not hit, it is determined that the current real-time communication toolkit version does not enable the address sanitizer, and the address sanitization compilation option is not added to the compilation and linking parameter set, thereby avoiding undefined symbols or runtime conflicts caused by forcibly injecting the address sanitization flag into an unsanitized library.

[0103] When both the wake-up static library file and the real-time communication static library file exist, the file type judgment method takes precedence. At the same time, the address sanitization compilation option is added to the compilation and linking parameter set, and the multi-definition linker flag is added to the compilation and linking parameter set to handle potential runtime symbol redefinition conflicts of the address sanitizer.

[0104] The dual-mode detection mechanism, which executes sequentially according to priority, ensures that the assembly of address sanitization compilation options can be correctly identified in different toolkit types and versions, achieving zero omissions.

[0105] Version macro compilation options are defined by specific enumerations in the header file as content fingerprints, automatically detecting the application interface version and adding the corresponding version macros to the compilation and linking parameter set.

[0106] Version macro compilation options address the issues of application interface version ambiguity and missing version macro configurations. Without relying on external version configuration tables or manual version documentation, it directly uses specific enumeration definitions in header files as content fingerprints, mapping and binding objective facts in the code to compilation macros, achieving an automatic mapping relationship between content, characteristics, and version macros. Even if the version number marking is incorrect, the enumeration definition in the code can still be objectively recognized by the compiler, ensuring the accuracy of version macro injection.

[0107] In one embodiment, the enumeration definitions in the header information of the compiled source file are extracted as content fingerprints; when the content fingerprint contains a session description protocol compression mode enumeration, a first version macro definition is added to the compilation and linking parameter set; when the content fingerprint contains a wake-up exit mode enumeration, a second version macro definition is added to the compilation and linking parameter set.

[0108] In existing embedded real-time communication toolkit testing solutions, version macro definitions for compilation and linking parameters rely on manual configuration after consulting version documentation, failing to automatically detect changes in header file application interfaces. Different toolkit versions have different application interface structure fields, leading to a high omission rate in manual version macro configuration, and configuration errors result in numerous application interface mismatch errors during compilation. Furthermore, toolkit version number marking may contain human errors, while enumeration definitions in the code are objective facts determined by the compiler. Existing solutions lack a mechanism for version determination based on these objective facts, making it impossible to avoid configuration biases caused by version number marking errors.

[0109] In this embodiment, a specific enumeration is defined in the header file as a content fingerprint, which automatically detects the application interface version and adds the corresponding version macro to the compilation and linking parameter set.

[0110] Specifically, instead of relying on external version configuration tables, release documentation, or manually labeled version number strings, it directly performs content scanning on the header information of the compiled source files and extracts the enumeration definitions (a data type declaration consisting of a set of named constants) as content fingerprints.

[0111] Content fingerprints refer to specific enumeration definitions and function signatures in the header file that can uniquely identify the version or capability characteristics of the toolkit. Essentially, they use specific type definitions and function signatures in the header file as digital fingerprints of the toolkit version to characterize the application interface version characteristics of the current toolkit, and are not affected by external version number markings.

[0112] Understandably, the version number string annotated when a toolkit is released may differ from the actual code due to human error, outdated documentation, branch merge conflicts, or build system configuration errors. However, once enumeration definitions and function signatures are written into header files, they become objective facts that the compiler must process during syntax analysis and semantic checking, possessing unforgeability and strong consistency. Therefore, by scanning enumeration definitions as content fingerprints, a version-aware paradigm shift from "depending on external configuration" to "depending on code facts" is achieved.

[0113] In one specific embodiment, a text retrieval tool (grep, a global regular expression search tool) or lightweight lexical analysis is used to scan enumeration type declaration keywords (enum) and their subsequent type identifiers and enumeration member lists in toolkit header files (such as rtc_defines.h, wakeup_defines.h, etc.), and the extracted set of enumeration names is used as a content fingerprint. This process does not require complete parsing of the abstract syntax tree of the header file, but only needs to match specific enumeration name patterns, ensuring accuracy while maintaining detection efficiency.

[0114] When the content fingerprint contains ESdpCompressionMode (session description protocol compression mode enumeration), it is determined that the current toolkit has the sixth.0 version characteristics, and the first version macro definition (-DRTC_SDK_VER_899) is added to the compilation and linking parameter set.

[0115] The Session Description Protocol (SDP) compression mode enumeration is a significant new feature in WiFi RTC SDK version 6.0. It controls the compression encoding mode of the SDP. Enumeration members typically include options such as no compression, basic compression, and advanced compression. The existence of this enumeration indicates that the current toolkit supports fine-grained media negotiation capabilities. The corresponding conditional compilation branches in the test source code (such as the new application programming interface call code wrapped in #ifdefRTC_SDK_VER_899) need to be activated using this version's macros.

[0116] By establishing a mapping and binding relationship between the session description protocol compression mode enumeration, the sixth-point zero version feature and the first version macro definition, the injection of version macros is completed automatically, eliminating the need for testers to manually check the release notes and add compilation flags.

[0117] When the content fingerprint contains WakeUpExitMode (wake-up exit mode enumeration), it is determined that the current toolkit has the new version of wake-up control features, and the second version macro definition (-DWAKEUP_SDK_HAS_EXIT_MODE) is added to the compilation and linking parameter set.

[0118] The wake-up exit mode enumeration is a hallmark of the new state machine management capabilities of the 4G WakeUp SDK, used to define various modes for a device to exit from the wake-up state (such as normal exit, timeout exit, abnormal interruption exit, etc.). The existence of this enumeration indicates that the current wake-up control toolkit has enhanced wake-up lifecycle management capabilities. The corresponding conditional compilation branches in the test source code (such as the new exit control logic wrapped in #ifdef WAKEUP_SDK_HAS_EXIT_MODE) need to be activated through this version of the macro.

[0119] By establishing a mapping and binding relationship between the wake-up exit mode enumeration, the new wake-up control features, and the second version macro definition, the injection of version macros is automatically completed.

[0120] Both the first and second version macro definitions are injected into the compilation and linking parameter set in the form of -D (Macro Definition Flag). Their technical function is to register conditional compilation macros with the compiler preprocessor during the preprocessing stage. This allows conditional compilation directives in the test source code (such as #ifdef, #ifndef, #if defined, etc.) to selectively include or exclude specific code blocks based on the actual version characteristics of the current toolkit. For example, if the test source code contains code accessing a V6.0-specific structure field wrapped in #ifdef RTC_SDK_VER_899, if the platform correctly injects this version macro, the preprocessor will retain the code block; if not injected, the code block will be excluded, thus avoiding compilation errors caused by accessing non-existent fields on older toolkit versions.

[0121] The above-mentioned fingerprint-driven version macro automatic injection mechanism eliminates the risk of omission and efficiency loss caused by manually defining compilation macros after manually reading the release notes in the existing technology, reduces the compilation configuration omission rate to zero, and realizes the technological leap from manual version awareness to automatic code fact awareness.

[0122] This embodiment generates a complete set of compilation and linking parameters through the above-mentioned link library list assembly, address sterilizer dual-mode detection, and version macro automatic injection, providing standardized and complete input for the compiler to perform compilation and linking operations subsequently.

[0123] S104. Based on the dynamic library files in the toolkit directory, construct a basic symbolic link environment, and perform transitive dependency completion on the basic symbolic link environment based on runtime dependency requirements to obtain a closed symbolic link environment.

[0124] Current embedded real-time communication toolkit testing solutions limit dynamic library dependency management to first-level direct dependencies, failing to handle transitive dependencies in nested shared object name version chains. This is particularly problematic for dynamic libraries like the secure transport layer protocol library, which exhibits nested shared object name version chains. These libraries require not only aligning direct dependencies but also recursively resolving transitive dependencies. Current solutions only handle first-level direct dependencies, making them prone to oversight during manual checks and leading to frequent runtime errors preventing the opening of shared object files. Furthermore, the toolkit directory may contain erroneous shared object name files and symbolic links from earlier versions, as well as remnant files from different versions. Current solutions lack proactive cleanup mechanisms, resulting in chaotic symbolic links and cross-contamination. Additionally, when the toolkit directory contains only versioned dynamic library files without bare name files, references to non-versioned library names will fail during the compilation and linking phase.

[0125] Please refer to Figure 6 , Figure 6 This is a sequence diagram illustrating the recursive name resolution and symbolic link reconstruction process within a dynamic library, provided in an embodiment of this application. Figure 6 As shown, this sequence diagram involves three interactive objects: the toolkit directory (.so files), the test platform (build_helper.sh), and the object file parsing tool (objdump / nm). The sequence of steps includes: 1. The test platform, based on its version evolution history experience library, proactively cleans up known erroneous internal name files and symbolic links (such as libmbedtls.so.13 and libmbedcrypto.so.6), and also cleans up residual files across versions; 2. The test platform executes `objdump -p` on each dynamic library file in the toolkit directory to extract the internal name (SONAME) field, and creates a two-level symbolic link (internal name symbolic link and bare name symbolic link) based on the extraction results, thus constructing the basic symbolic link environment; 3. Starting with the network transport library dynamic library file (libcurl.so), the test platform executes `objdump -p` to extract the runtime dependency list from its required dependencies (NEEDED) field; 4. Based on the runtime dependency list, the test platform performs transitive dependency completeness verification on the basic symbolic link environment, and uses a prefix matching completion strategy to create complete symbolic links for missing items; 5. If prefix matching does not find any version file, a warning message containing the name of the missing dependency is output; 6. The test platform submits the closed symbolic link environment to the compiler / loader.

[0126] This embodiment receives a cleaned-up compilation environment (a toolkit directory with residual files cleaned up), and performs recursive resolution of internal names (SONAME, Shared Object Name) and reconstruction of symbolic links (symbolic references) on the dynamic library files (Dynamic Library, shared object files, with the .so extension) in the toolkit directory. This expands the scope of dynamic library dependency management from the traditional single-level direct dependency to multi-level transitive dependency chains. Through a two-stage processing mechanism from both the supply and demand sides, it achieves recursive resolution of shared object names and reconstruction of symbolic links in dynamic libraries, constructing a closed symbolic link environment that fully covers the supply and demand sides.

[0127] The two-stage processing mechanism comprehensively covers dynamic library dependency management from both the supply and demand sides. Specifically, Stage 1 focuses on the dynamic library files themselves, addressing the question of what is actually available. This is achieved by extracting the self-declared shared object names of each library file and creating two-level symbolic links, ensuring that the library files can be found by their declared names. Stage 2 focuses on library files transmitted over the network, addressing the question of what is actually needed at runtime. This is achieved by extracting their required dependency fields to create a requirements list, checking each item against the results of Stage 1, and filling any gaps using prefix matching. By processing different files in each stage, the two stages avoid omissions from a one-way perspective, expanding the scope of dynamic library dependency management from single-level direct dependencies to multi-level transitive dependency chains.

[0128] In one embodiment, in stage one, based on the dynamic library files in the toolkit directory, the internal names are automatically extracted and a basic symbolic link environment is constructed. Specifically, this includes: extracting the internal name field of each dynamic library file; creating two-level symbolic links based on the internal name fields, and constructing the basic symbolic link environment.

[0129] Before extracting the internal name field, based on the version evolution history experience library, we proactively clean up known erroneous shared object name files and symbolic links, including erroneous shared object name files and symbolic links from earlier versions such as erroneous versions of the secure transport layer protocol library and cryptographic primitive library. At the same time, we clean up residual files in the toolkit directory that are incompatible with the current toolkit type to prevent cross-contamination and symbolic link corruption.

[0130] Then, iterate through the actual dynamic shared object files in the toolkit directory, and execute the object file parsing command (objdump -p, Object File Dump with Program Headers) on each dynamic library file to extract the internal name field (SONAME, Shared Object Name) from its Executable and Linkable Format (ELF) dynamic segment. These dynamic shared object files include the secure transport library main library (e.g., libmbedtls.so.2.25.0), the secure transport library cryptography module (e.g., libmbedcrypto.so.2.25.0), and the secure transport library certificate module (e.g., libmbedx509.so.2.25.0).

[0131] The internal name field is a self-declared identifier string written by the linker (linking editor) to the dynamic segment of the ELF file during the compilation and linking phase. It tells the runtime dynamic linker (ld.so, DynamicLinker / Loader) the exact name to match when loading the library. For example, the internal name field of the main file of the secure transport library, libmbedtls.so.2.25.0, might be "SONAME libmbedtls.so.13", indicating that although the actual version of the file is 2.25.0, it is requested and loaded at runtime under the name libmbedtls.so.13. This field is core metadata for dynamic library version management and runtime resolution, directly determining whether the dynamic linker can correctly locate the required library instance in the file system.

[0132] Based on the extracted internal name field, a dual-layer symbolic link is created for each dynamic library file. The dual-layer symbolic link includes internal name symbolic links and non-versioned symbolic links, and the basic symbolic link environment is built through the dual-layer structure.

[0133] In one embodiment, an internal name symbolic link is created to point the internal name to the actual library file, so as to meet the runtime dynamic linker's need for finding the precise internal name; a non-versioned symbolic link is created to point the non-versioned dynamic library name to the actual library file, so as to meet the need for referencing the non-versioned library name during the compilation and linking stage.

[0134] The first level of a two-level symbolic link is an internal name symbolic link.

[0135] For each dynamic library file, a symbolic link is created using the self-declared internal name field (SONAME, Shared Object Name) in its executable linker format (ELF, Executable and LinkableFormat) header as the link source and the actual library file name as the link target. For example, for the actual library file libmbedtls.so.2.25.0, if its internal name field is libmbedtls.so.13, then the symbolic link libmbedtls.so.13 → libmbedtls.so.2.25.0 is created.

[0136] The technical principle behind this internal name symbolic linking is as follows: During program startup, the runtime dynamic linker (ld.so, DynamicLinker / Loader) precisely searches the file system according to the internal name string recorded in the executable file or its dependent libraries. The internal name string is a self-declared identifier written into the ELF dynamic segment by the linker (linking editor) during compilation. The runtime loader does not intelligently resolve version number suffixes (such as .so.2.25.0), but strictly searches for filenames that exactly match the internal name.

[0137] By creating internal name symbolic links, the dynamic linker's exact lookup request is redirected to the actual library file version existing in the toolkit directory, ensuring successful runtime library loading. Without this layer of symbolic links, even if a fully compatible library file exists in the toolkit directory, the dynamic linker will report a "cannot open shared object file" error because it cannot find an exact matching internal name file, causing the test executable to fail to start.

[0138] The second layer of a double-layer symbolic link is a non-versioned symbolic link, i.e., a naked name link.

[0139] For each dynamic library file, create a non-versioned symbolic link with the unversioned raw dynamic library name as the link source and the actual library file name as the link target. For example, for the actual library file libmbedtls.so.2.25.0, create the symbolic link libmbedtls.so → libmbedtls.so.2.25.0.

[0140] The technical principle behind this non-versioned symbolic link is as follows: During the compilation and linking phase, when the test source code specifies external dependencies using the -lmbedtls (linking library option) format, the linker, according to convention, converts the -l option into a bare name format with the lib prefix and .so suffix (i.e., libmbedtls.so), and searches for this bare name file in the library search path.

[0141] By creating non-versioned symbolic links, the linker's raw name lookup requests are redirected to the actual library files, allowing library dependency resolution to be completed during the compilation and linking phases without hardcoding specific version numbers. This mechanism decouples compile-time dependency declarations from runtime library versions: testers only need to declare non-versioned library names in the compilation configuration, and the actual versions are dynamically pointed to by symbolic links in the toolkit directory, thus supporting seamless migration of the same compilation configuration between different versions of toolkits.

[0142] Internal name symbolic links and non-versioned symbolic links together constitute the basic symbolic link environment. This environment covers both runtime precise lookup scenarios and compile-time non-versioned reference scenarios, ensuring that each dynamic library file in the toolkit directory has dual symbolic link entries.

[0143] Through the two-layer structure of internal name symbolic links and non-versioned symbolic links, the dual lookup requirements of dynamic libraries during the compilation and runtime stages are fully covered from the supply side perspective, building a basic symbolic link environment and providing underlying support for subsequent dependency completion from the demand side.

[0144] The first phase of the process solves the problem of "what is actually on the supply side," ensuring that the library files that actually exist in the toolkit directory can be correctly found according to their own declared internal names and the bare names expected by the compiler.

[0145] After completing the master resolution of internal names on the supply side and building the basic symbolic link environment in Phase 1, the platform has ensured that the dynamic library files that actually exist in the toolkit directory can be correctly indexed according to their self-declared internal names and unversioned bare names.

[0146] However, this basic symbolic linking environment only covers the naming requirements from the perspective of the library file itself, and does not yet verify whether the versions of other dynamic libraries in the toolkit (such as the network transport library) actually linked at compile time are consistent with the library versions provided in the current directory. Specifically, the network transport library dynamic library file records all the required runtime dependencies in its executable and linkable header. The internal name version numbers of its dependencies may have coverage gaps with the symbolic links created in stage one, causing the runtime dynamic linker to fail to find a matching library file according to the network transport library's dependency requests.

[0147] Therefore, in Phase Two of this application, from the perspective of the demand side, starting with the dynamic library file of the network transport library, the runtime dependency requirement list is extracted, and the transitive dependency completeness of the basic symbolic link environment is checked and completed, thereby achieving a closure of the supply and demand sides from two perspectives.

[0148] In one embodiment, starting with a network transport library file, the required dependency fields in its executable and linkable format header are extracted using object dump instructions to obtain a list of shared object names that depend on it at runtime; based on the list of runtime dependencies, transitive dependency completeness is checked on the basic symbolic link environment; for missing items in the check, a prefix matching completion strategy is used to create completed symbolic links to obtain the closed symbolic link environment.

[0149] Starting with the network transport library dynamic library file (libcurl.so, Client URL Library, network transport library shared object file), an existence guarantee operation is performed: if only the network transport library file with a version number exists in the toolkit directory (such as libcurl.so.4.7.0, commonly found in wireless LAN real-time communication toolkits), then a symbolic link is created pointing to the version-numbered library file (i.e., libcurl.so → libcurl.so.4.7.0); if the network transport library dynamic library exists directly in the directory (commonly found in fourth-generation mobile communication wake-up toolkits), then this step is skipped. This unifies the operation objects of subsequent object dump commands, ensuring that regardless of whether the toolkit uses versioned naming or bare-name naming, it can be resolved through the standardized entry point of libcurl.so.

[0150] Subsequently, the object dump command (objdump -p, Object FileDump with Program Headers) is executed on the network transport library dynamic library file to extract the required dependency field (NEEDED, ELFDynamic Dependency Field) from the dynamic segment of its Executable and Linkable Format (ELF) header. The required dependency field records the internal names (SONAME, Shared ObjectName) of other shared libraries that the executable and linkable format file depends on during loading. For example, the network transport library might declare dependencies on libmbedtls.so.13, libmbedcrypto.so.6, etc.

[0151] The extracted fields of all required dependencies are compiled into a list of shared object names that are dependent on at runtime. This list constitutes the "dependency requirement list" on the demand side, which is used to verify the completeness of the coverage of the basic symbolic link environment on the supply side.

[0152] A wildcard pattern is used to filter secure transport dependencies from the list of shared object names that the runtime depends on. This wildcard pattern includes libmbedtls.so.* (the main secure transport library), libmbedcrypto.so.* (the cryptography module of the secure transport library), and libmbedx509.so.* (the certificate module of the secure transport library). These three libraries are responsible for the implementation of the Transport Layer Security (TLS) protocol, cryptographic primitive operations, and X.509 certificate parsing, respectively. They are transitive dependencies (indirect dependencies) that the network transport library uses to support the Hypertext Transfer Protocol Secure (HTTPS). Existing technologies only handle first-level direct dependencies and cannot identify such nested transitive dependency chains, leading to a runtime "cannot open shared object file" error.

[0153] For each selected secure transport dependency, check whether a file or symbolic link with the corresponding name already exists in the toolkit directory. The scope of the check includes the basic symbolic link environment (internal name symbolic links and non-versioned symbolic links) created in Phase 1, determining whether each runtime dependency declared by the network transport library is covered by the basic symbolic link environment. This item-by-item verification process is the transitive dependency completeness check, which can identify coverage gaps between the basic symbolic link environment and the actual runtime requirements of the network transport library.

[0154] When transitive dependency completeness checks detect a missing dependency—that is, when the required dependency name for the network transport library does not exist in a corresponding file or symbolic link in the toolkit directory—a prefix matching completion strategy is triggered. The technical basis of this prefix matching completion strategy is that the Application Binary Interface (ABI) of the Secure Transport library family typically maintains backward compatibility within the same major version family. Library files in different minor versions can satisfy runtime requirements for the same internal name. Therefore, by redirecting runtime requests to the actually existing compatible version through symbolic links, transitive dependency closure can be achieved.

[0155] Specifically, the version number suffix of missing dependencies is removed to obtain the base library name (e.g., extracting libmbedtls from libmbedtls.so.13). A file system prefix matching search (e.g., ls libmbedtls.so.*) is performed to find any version of the library that actually exists in the toolkit directory. If a match is found (e.g., libmbedtls.so.2.25.0 exists in the directory), the first match is selected to create a complete symbolic link (e.g., creating libmbedtls.so.13 → libmbedtls.so.2.25.0).

[0156] If the prefix match finds no version file (i.e., the file system search result is empty), then a warning message containing the name of the missing dependency (such as "WARNING: The corresponding version file of libmbedtls.so.13 cannot be found") is output to the standard error output port (stderr, standard error, standard error output) to ensure that the operation and maintenance personnel can discover and manually intervene to handle the missing dependency library in a timely manner.

[0157] By using the aforementioned demand-side transitive dependency completion starting with the network transport library, the scope of dynamic library dependency management can be expanded from a single-level direct dependency to a multi-level transitive dependency chain. Based on the superposition of the basic symbolic link environment and the completed symbolic links, a closed symbolic link environment is obtained. This closed environment ensures that full lookup requests for dynamic libraries during the compilation and linking stages and the program runtime stages can be correctly resolved, completely eliminating loading failures caused by broken transitive dependencies at runtime.

[0158] In this embodiment, Phase 1 addresses the question of "what we actually have" from the supply side's perspective, while Phase 2 addresses the question of "what we actually need at runtime" from the demand side's perspective. The version of the secure transport library linked by the network transport library during compilation may differ from the version actually provided in the toolkit directory (different internal names and version numbers), causing the links created in Phase 1 to not fully cover all runtime requirements of the network transport library. Phase 2 uses the network transport library's dependency requirement fields as a "requirement list," checking the results of Phase 1 item by item. If gaps are found, a prefix matching completion strategy is used to create complete symbolic links, achieving complete coverage from both the "supply" and "demand" perspectives and avoiding omissions from a one-way perspective.

[0159] Through the two-stage processing mechanism described above, the platform expands the scope of dynamic library dependency management from single-level direct dependencies to multi-level transitive dependency chains. Based on internal name symbolic links, non-versioned symbolic links, and completed symbolic links, a closed symbolic link environment is constructed. This closed environment ensures that dynamic library lookup requests during the compilation and linking stages and the program runtime stages can be correctly resolved, completely eliminating the runtime "cannot open shared object file" error.

[0160] S105. Based on the compiled source file, the complete set of compilation and linking parameters, and the closed symbolic linking environment, the compiler is triggered to perform compilation and linking operations to generate a test executable program, and test verification is completed based on the test executable program.

[0161] In existing embedded real-time communication toolkit testing solutions, the compilation and linking stages rely on manual configuration and error checking. Testers need to handle multiple steps, including source code selection, compilation option injection, and dynamic library linking. Oversights in any of these steps can lead to compilation failures. Especially in testing environments with multiple types and versions, manually switching toolkit types can take several minutes, and adding new test modules requires extensive manual adaptation work, resulting in overall low efficiency. Furthermore, when the test source code and toolkit type are incompatible, the existing solution directly outputs numerous compilation errors, requiring testers to spend a significant amount of time troubleshooting the root cause, lacking a degradation mechanism to convert hard errors into soft bootstrapping.

[0162] In this embodiment, based on the compiled source files (including the original test source code, the switched backup source files, or the automatically generated alternative program), the complete set of compilation and linking parameters (including the list of link libraries, address sanitization compilation flags, version macro compilation options, and linker flags), and the closed symbolic link environment (including internal name symbolic links, non-versioned symbolic links, and completion symbolic links), the compiler is triggered to perform compilation and linking operations to generate a test executable program. Based on the test executable program, the functional testing and verification of the embedded real-time communication (RTC) toolkit is completed.

[0163] The compiler uses source files as input, complete sets of compilation and linking parameters as control parameters for the compiler and linker, and closed symbolic linking environment as the underlying support for library file search paths, all of which are uniformly submitted to the compilation toolchain for compilation and linking operations.

[0164] Each parameter in the compilation and linking parameter set plays a specific technical role at different stages of compilation and linking.

[0165] Specifically, during the preprocessing stage, the compiler preprocessor receives the version macro compilation option (-D, Macro Definition Flag) and performs conditional compilation on the source files based on the macro definitions registered according to the content fingerprint mapping relationship.

[0166] For example, when `-DRTC_SDK_VER_899` is injected, the preprocessor preserves the version 6.0-specific code block wrapped by `#ifdef RTC_SDK_VER_899` in the test source code; when this macro is not injected, the corresponding code block is excluded. This technique ensures that the test source code only compiles application programming interface (API) calls that are actually compatible with the current toolkit version, avoiding compilation errors caused by accessing non-existent structure fields or function prototypes.

[0167] During the compilation phase, the compiler code generator receives the address sanitization compilation flag (-fsanitize=address, address sanitization compilation flag). When address sanitizer (ASAN, AddressSanitizer) is enabled, runtime checking code for memory error detection is inserted into the object file of each compilation unit. This runtime checking code covers error modes such as stack buffer overflow, heap buffer overflow, use-after-free, and global buffer overflow. If address sanitizer is not enabled in the current toolkit, the compiler does not insert the above checking code, ensuring that the compilation artifacts are consistent with the toolkit's original compilation strategy and avoiding runtime symbol conflicts.

[0168] During the linking phase, the linker receives a list of libraries to link and performs symbol resolution (symbol address binding) and relocation (address relocation) according to the static library files specified in the list (such as libwakeupsdk.a or librtcsdk.a) and dynamic library bare names (such as libcurl.so, libmbedtls.so). Linker flags (such as -Wl, --allow-multiple-definition, linker options allowing multiple definitions) in scenarios where two libraries coexist, instructing the linker to arbitrate global symbols with the same name instead of exiting with an error. Simultaneously, non-versioned symbolic links in the closed symbolic link environment (such as libmbedtls.so → libmbedtls.so.2.25.0) ensure that the linker can locate the actual library file by searching its bare name in the library search path, without needing to hardcode the version number.

[0169] After compilation and linking are complete, a test executable is output. The test executable is a machine code file that can be loaded and executed on the target embedded device or in a simulated runtime environment. It contains: test logic code segments (test case implementations from the compiled source file); toolkit interface call code segments (application interface calls adapted through conditional compilation); address sanitizer runtime library dependencies (if address sanitization compilation flags are enabled); and dynamic library dependency records (recorded in the required dependencies field of the Executable and Linkable Format (ELF) for the runtime dynamic linker to parse).

[0170] After successful compilation and linking, a test executable program is generated. Then, the test executable program is executed to complete the test verification. When a normal test executable program is generated, the actual test logic is executed and the test results are output. When a stub executable program is generated, user boot information is output after running, prompting the tester to switch to the matching toolkit type and retry, thus realizing the downgrade from hard error to soft boot.

[0171] The specific verification modes for testing and verification include: normal testing and verification path, friendly degradation verification path, and dynamic library loading verification path.

[0172] In the normal testing and verification path, if the compiled source file is the original test source code or backup source file that matches the current toolkit type, the test executable program will load the toolkit interface normally and perform real-time communication function verification. For example, in the wireless LAN real-time communication type, it verifies video call establishment, media stream transmission, and signaling interaction; in the wake-up control type, it verifies remote wake-up command issuance, device state switching, and low-power signaling response. The address sterilizer continuously monitors memory access behavior while running in the background. If a memory error is detected, it immediately outputs an error report and terminates the program to help locate memory safety issues in the toolkit or test code.

[0173] In the friendly degradation verification path, if the compiled source file is an automatically generated alternative program (stub program), the test executable will print user boot information (e.g., "This test requires the Wireless LAN Real-Time Communication Toolkit. Please press 's' in the main menu to switch the toolkit version to the Wireless LAN type and then try again") when it runs. Testers do not need to read the compiler error stack trace to directly understand the root cause of the type mismatch and the recovery instructions, achieving abnormal self-healing from "hard error termination" to "soft boot continuation".

[0174] In the dynamic library loading verification path, when the test executable starts, the operating system loader (Loader) calls the dynamic linker (ld.so), which searches for the corresponding library file in the closed symbolic link environment according to the internal name list in the executable's required dependency fields. Internal name symbolic links (e.g., libmbedtls.so.13 → libmbedtls.so.2.25.0) ensure that the dynamic linker accurately matches and loads the correct version of the library file, completely eliminating the runtime "cannot open shared object file" error. If all transitive dependencies are closed, the program successfully loads the library and enters the test logic; if there are incomplete missing dependencies, the dynamic linker reports a loading failure, and testers can locate the missing library file based on the warning message.

[0175] Please refer to Figure 7 , Figure 7 A comparison chart of key indicators between the technical solution of this invention and the traditional technical solution provided in the embodiments of this application. (See figure.) Figure 7 As shown in the image, the top chart compares time-related metrics, including: toolkit version switching time reduced from approximately 5 minutes to approximately 3 seconds, an improvement of 99%; multi-toolkit environment configuration time reduced from 2-3 days to approximately 1 hour, an improvement of 95%; and new test module adaptation time reduced from approximately 4 hours to approximately 30 minutes, an improvement of 87%. The bottom chart compares error rate / omission rate metrics, including: dynamic library linking error rate reduced from approximately 15% to 0% (completely eliminated); and compilation configuration omission rate reduced from approximately 20% to 0% (completely eliminated). Both no longer require manual investigation and correction. Figure 7 This demonstrates the significant advantages of the proposed method over traditional manual methods in terms of time efficiency and error rate control.

[0176] Through the above compilation and linking operations and testing verification, the test execution results are output, realizing full-link automation from toolkit type identification, source code adaptation, parameter assembly, dependency closure to compilation verification, ensuring that the test executable program can be stably generated and run correctly in an embedded real-time communication test environment where multiple types and versions coexist.

[0177] This embodiment provides a method for compiling and testing multi-type embedded real-time communication toolkits. This method detects the existence of core static library files in the toolkit directory and automatically determines the current toolkit type based on the determination result, avoiding type misjudgment caused by manual identification. It obtains the header file reference types of the test source code and matches them with the current toolkit type to determine the compilation source file, achieving automatic adaptation between the test source code and the toolkit type, avoiding compilation errors caused by type mismatch. Based on the current toolkit type and the header file information of the compilation source file, it dynamically assembles compilation and linking parameters to generate a compilation and linking parameter set, achieving automated configuration of compilation parameters and avoiding manual intervention. This process addresses omissions or mismatches in toolkit configuration; it constructs a basic symbolic link environment based on dynamic library files in the toolkit directory, and completes transitive dependencies in the basic symbolic link environment based on runtime dependency requirements to obtain a closed symbolic link environment. This achieves automatic closure of multi-level transitive dependency chains for dynamic libraries, avoiding transitive dependency breaks caused by handling only first-level direct dependencies. Finally, based on the compiled source files, the complete set of compilation and linking parameters, and the closed symbolic link environment, the compiler is triggered to perform compilation and linking operations to generate test executable programs and complete test verification. This achieves full-link automation of compilation and testing in toolkit type switching and dynamic library linking scenarios, improving the reliability of compilation and testing.

[0178] This application also provides a memory card that stores processor-executable instructions, which can be loaded by one or more external processors to execute the above-mentioned compilation and testing methods for multi-type embedded real-time communication toolkits.

[0179] The core function of the memory card is to physically encapsulate the entire software intelligence of the "multi-type embedded real-time communication toolkit compilation and testing method" into an independent hardware carrier. This means that even testers lacking extensive embedded development experience no longer need to deal with tedious environment configuration, parameter debugging, and script writing.

[0180] Users simply insert this memory card into any device equipped with a standard external interface (such as USB, SD card slot, etc.) (such as computers, industrial control computers, and even some high-end embedded development boards), and the device immediately obtains a complete, fully automated compilation and testing engine. This achieves a revolutionary shift from "software installation and configuration" to "hardware plug and play," greatly reducing the technical threshold and making testing tasks as simple and direct as "plug and play."

[0181] Because the memory card itself is an independent, closed system, its dependence on external devices is minimized. Even with slight differences in the operating systems and software environments of external devices, the instruction set inside the memory card can run independently and stably. This design greatly enhances the robustness (anti-interference capability) of the entire testing system. At the same time, it also provides the most direct hardware bridge for porting this method to more different types of embedded platforms (such as IoT gateways based on ARM and RISC-V architectures) in the future.

[0182] It should be noted that, for the sake of convenience and brevity, the specific working process of the memory card described above can be referred to the corresponding process in the aforementioned multi-type embedded real-time communication toolkit compilation and testing method embodiment, and will not be repeated here.

[0183] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for compiling and testing a multi-type embedded real-time communication toolkit, characterized in that, The method includes: The existence status of at least one core static library file in the toolkit directory is detected, and the current toolkit type is determined based on the result of the existence status determination. Obtain the header file reference type of the test source code, and match the header file reference type with the current toolkit type to determine the source file to be compiled; Based on the current toolkit type and the header file information of the compiled source file, dynamically assemble compilation and linking parameters to generate a set of compilation and linking parameters; Based on the dynamic library files in the toolkit directory, a basic symbolic link environment is constructed, and transitive dependency completion is performed on the basic symbolic link environment based on runtime dependency requirements to obtain a closed symbolic link environment. Based on the source file, the complete set of compilation and linking parameters, and the closed symbolic linking environment, the compiler is triggered to perform compilation and linking operations, generate a test executable program, and complete test verification based on the test executable program.

2. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 1, characterized in that, The determination of the current toolkit type based on the existence status includes: When a wake-up static library file exists in the toolkit directory, but a real-time communication static library file does not exist, the current toolkit type is determined to be wake-up control type. When the real-time communication static library file exists in the toolkit directory, but the wake-up static library file does not exist, the current toolkit type is determined to be real-time communication type; When the wake-up static library file and the real-time communication static library file coexist, a conflict arbitration mechanism is triggered, marking the conflict coexistence state and determining the current toolkit type as wake-up control type.

3. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 2, characterized in that, The determination of the current toolkit type based on the existence status determination result also includes: When neither the wake-up static library file nor the real-time communication static library file exists, extract the path string to be matched from the toolkit directory; If the path string to be matched contains at least one item from the set of wake-up control type keywords, then the current toolkit type is determined to be wake-up control type; If the path string to be matched contains at least one item from the set of keywords for real-time communication types, then the current toolkit type is determined to be real-time communication type; If the path string to be matched contains keywords from both the wake-up control type keyword set and the real-time communication type keyword set, then the current toolkit type is determined to be wake-up control type.

4. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 1, characterized in that, The step of matching the header file reference type with the current toolkit type to determine the compilation source file includes: When the header file reference type successfully matches the current toolkit type, the test source code is determined as the compilation source file; When the header file reference type fails to match the current toolkit type, the backup source file corresponding to the current toolkit type is switched as the compilation source file; If the backup source file is not available, a compilable alternative program is generated as the compilation source file, wherein the alternative program outputs user boot information when it runs.

5. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 1, characterized in that, The process of dynamically assembling compilation and linking parameters and generating a set of compilation and linking parameters based on the current toolkit type and the header file information of the compiled source file includes: Based on the current toolkit type, assemble the list of link libraries and add the list of link libraries to the compilation and linking parameter set; The address sterilizer compilation option detection is performed, and the directory of the toolkit is checked to obtain the directory detection results. If the directory detection result indicates that a wake-up static library file exists in the toolkit directory, then the current toolkit is determined to be of the wake-up control type, and the address sanitization compilation option is added to the compilation and linking parameter set; If the representation indicates that a real-time communication static library file exists in the toolkit directory, then the symbol table of the real-time communication static library file is scanned, and when an address sanitization prefix symbol is detected in the symbol table, the address sanitization compilation option is added to the compilation and linking parameter set.

6. The compilation and testing method for the multi-type embedded real-time communication type toolkit according to claim 1, characterized in that, The step of dynamically assembling compilation and linking parameters and generating a set of compilation and linking parameters based on the current toolkit type and the header file information of the compiled source file also includes: Extract the enumeration definitions from the header information of the compiled source file as the content fingerprint; When the content fingerprint contains a session description protocol compression mode enumeration, the first version macro definition is added to the compilation and linking parameter set; When the content fingerprint contains a wake-up exit mode enumeration, the second version macro definition is added to the compilation and linking parameter set.

7. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 1, characterized in that, The construction of the basic symbolic link environment based on the dynamic library files in the toolkit directory includes: Extract the internal name field of each of the aforementioned dynamic library files; A two-layer symbolic link is created based on the internal name field to build the basic symbolic link environment.

8. The compilation and testing method for the multi-type embedded real-time communication type toolkit according to claim 7, characterized in that, The process of creating a two-layer symbolic link based on the internal name field and constructing a basic symbolic link environment includes: Create symbolic links for internal names, pointing the internal names to the actual library files, to meet the runtime dynamic linker's need for precise internal name lookup. Create a non-versioned symbolic link to point the non-versioned dynamic library name to the actual library file, so as to meet the requirements of the compilation and linking stages for referencing non-versioned library names.

9. The compilation and testing method for the multi-type embedded real-time communication toolkit according to claim 7, characterized in that, The process of performing transitive dependency completion on the basic symbolic link environment based on runtime dependency requirements to obtain a closed symbolic link environment includes: Starting with the network transport library file, extract the required dependency fields from its executable and linkable format header using the object dump instruction to obtain the list of shared object names that it depends on at runtime; Based on the runtime dependency list, the transitive dependency completeness of the basic symbolic link environment is verified. For the missing items in the verification, a prefix matching completion strategy is used to create complete symbolic links, thereby obtaining the closed symbolic link environment.

10. A memory card storing processor-executable instructions, said instructions being loaded by one or more processors to perform the compilation and testing method for a multi-type embedded real-time communication type toolkit as described in any one of claims 1 to 9.

Images