Shared Library Constructor for Runtime Component Version Selection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The inefficiency and error-prone nature of requiring users to manually inform runtime linkers about the locations of shared libraries and runtime components, especially in environments with multiple versions, leads to complexities in dynamic linking processes.
Innovation Solution
Shared libraries utilize constructors to search for and configure themselves to use compatible versions of runtime components within the file system, eliminating the need for hard-coded directories and user-manual location inputs by autonomously determining and recording the paths of compatible components.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If users manually inform runtime linkers about the locations of shared libraries and runtime components, then the runtime linker can locate and load the required components, but the process becomes inefficient and error-prone especially in environments with multiple versions
Solution Approach 1:
The shared library performs self-service by autonomously searching for and identifying compatible runtime components using its own constructor code. The constructor executes during application initialization, automatically searching directories in the file system for runtime components that match version criteria without requiring user input or manual configuration.
Solution Approach 2:
The patent applies preliminary action by having the shared library's constructor search for and identify compatible runtime component versions before the runtime linker performs the binding operation. This preliminary identification ensures that when the runtime linker loads the shared library, the compatible runtime component is already identified and ready for binding, preventing version mismatches.
2Adaptability or versatility
If hard-coded directories are used for runtime linker to search, then the search process is simple, but it lacks flexibility in locating runtime components in various file system locations
Solution Approach 1:
The shared library autonomously performs the search for runtime components by executing its own constructor code that implements a flexible directory search mechanism. This self-service approach allows the shared library to adapt to different file system locations and configurations without requiring the runtime linker to be configured with multiple hard-coded directories or complex search paths.
3Adaptability or versatility
If multiple versions of runtime components are present in the file system, then version selection flexibility increases, but determining the correct compatible version becomes complex and error-prone
Solution Approach 1:
The shared library autonomously determines compatible runtime component versions by executing its constructor, which implements version matching logic. The constructor compares the shared library's version requirements against available runtime component versions in the file system, automatically identifying and selecting the most appropriate compatible version without user intervention.
Solution Approach 2:
The patent implements feedback by having the shared library's constructor evaluate available runtime component versions against compatibility criteria and adjust its selection based on the results. The constructor searches for runtime components, evaluates their compatibility with the shared library's requirements, and selects the appropriate version based on this feedback loop, ensuring version compatibility.
4Reliability
If the runtime linker loads all shared libraries and runtime components, then complete functionality is ensured, but memory usage and loading time increase
Solution Approach 1:
The patent extracts the version identification and selection logic from the runtime linker and places it within the shared library's constructor. This extraction allows the shared library to autonomously identify and specify only the runtime components it needs, enabling the runtime linker to load only those specific components rather than all available shared libraries and runtime components, thereby reducing memory usage and loading time while maintaining functionality completeness.
Data Source
AI summary
An electronic device includes a processor and a storage device having a file system with a plurality of directories. The processor executes an application that has a dependency on a shared library, the shared library having a dependency on a runtime component. When executing the application, the processor loads the shared library, the loading including executing a constructor for the shared library. Executing the constructor causes the processor to identify a selected directory where a compatible version of the runtime component is to be found based on a location of the shared library in the file system, the location of the shared library being determined from an application context from the application. When subsequently loading the runtime component for execution, the processor locates the runtime component in the selected directory.