Static Library

A static library is linked directly into the executable during the compilation phase. The linker resolves all external references by copying the necessary object code from the library archive (.a on Unix-like systems, .lib on Windows) into the final binary. This creates a self-contained executable with no runtime dependency on the library file.

• Result: The library code becomes a permanent, inseparable part of the application binary.
• Contrast with Dynamic Linking: Unlike a dynamic/shared library (.so, .dll), the OS loader does not need to locate and load a separate library file at program startup.

Because all necessary library code is copied into the executable, the resulting binary has no external dependencies on the library files at runtime. This is critical for NPU deployment in embedded or edge environments where:

• A specific, complex filesystem may not be guaranteed.
• Deployment simplicity and reliability are paramount.
• Versioning conflicts ("DLL Hell") must be eliminated.
• The binary may be flashed directly to device memory.

Trade-off: The executable file size increases, as it contains all the library code it uses.

Static linking enables powerful link-time optimizations (LTO). Since the linker has a complete view of all the application and library code being combined, it can perform whole-program optimizations that are impossible with separate compilation. For NPU code, this can include:

• Dead code elimination: Removing unused functions from the linked library.
• Function inlining: Inlining small library functions directly into calling code, eliminating call overhead.
• Inter-procedural optimization (IPO): Optimizing across function and module boundaries.
• Constant propagation and more aggressive loop optimizations.

This can lead to faster, more efficient machine code for the target accelerator.

Vendor NPU SDKs often distribute critical low-level routines—such as driver APIs, memory management primitives, and optimized kernel launchers—as static libraries. This serves several purposes:

• Protects Intellectual Property: The vendor's proprietary algorithms and hardware-specific code are distributed as opaque object code.
• Ensures Binary Compatibility: Guarantees the library is compiled with the correct flags and ABI for the vendor's toolchain and runtime.
• Simplifies Toolchain: Developers link against libvendor_npu.a without needing the vendor's full source code.
• Example: NVIDIA's CUDA Toolkit includes static libraries like libcudart_static.a for the CUDA Runtime.

Using static libraries affects the development workflow for NPU applications:

• Build Time: Linking can be slower, as the linker must process and copy large amounts of object code.
• Memory Footprint: If multiple executables on a system use the same static library, each contains its own copy, increasing total system memory usage ("code bloat").
• Updates: To update a library, every application that uses it must be recompiled and redeployed. This is often acceptable for firmware or embedded appliances but cumbersome for desktop software.
• Debugging: Debug symbols may be included in the static library, allowing source-level debugging, or they may be stripped, making debugging more difficult.

Understanding the trade-offs between static and dynamic libraries is crucial for system design.

For NPU code deployed on a single-purpose device, the self-containment of static libraries is often preferred.

Static libraries are essential for bundling hand-optimized kernels and hardware intrinsics into a single, efficient binary. This eliminates the runtime overhead of dynamic linking, ensuring deterministic execution latency for inference workloads. For NPUs, libraries often contain vendor-optimized routines for core operations like matrix multiplication (GEMM) or convolution.

• Example: A library libnpu_gemm.a containing assembly-optimized GEMM kernels for a specific NPU microarchitecture.
• Benefit: Guarantees that the fastest possible kernel is always used, as it's physically part of the application binary.

By linking all necessary code statically, the final executable becomes a self-contained binary. This simplifies deployment to edge devices or embedded NPU systems, as there are no external library dependencies to manage or version mismatch issues. It's crucial for cross-compilation scenarios where the target NPU runtime environment may be minimal or locked down.

• Use Case: Deploying an AI model to a smart camera with a proprietary NPU. The single .elf file contains the model, the inference engine, and all vendor-specific acceleration libraries.
• Trade-off: Increases binary size, as shared code cannot be reused across multiple applications on the same device.

Hardware vendors commonly distribute their proprietary APIs and low-level drivers as closed-source static libraries (.a or .lib files). This allows them to expose optimized functionality while protecting their intellectual property and hardware-specific implementation details.

• Mechanism: Developers link against libVendorNPU.a and included header files. The library's object code is merged into the final application, but the original source remains hidden.
• Consequence: Limits deep optimization by the end-developer, as they cannot see or modify the library's internal algorithms.

Static linking allows the linker to perform whole-program optimization at link time, a process known as Link-Time Optimization (LTO). The linker can see all object files (including those from the static library) and can inline functions, remove dead code, and optimize across module boundaries. Furthermore, the memory addresses of all functions and data are resolved at link time, creating a predictable layout.

• Impact on NPUs: Enables more aggressive optimization of the entire computational graph scheduled for the accelerator. The linker can also place frequently accessed constant weights or look-up tables in optimal memory sections defined by the linker script.

For bare-metal or lightweight RTOS environments on NPU-equipped microcontrollers, a minimal runtime library is often built as a static library. This library provides essential services like memory allocation for NPU buffers, synchronization primitives, and a thin dispatch layer to the kernel driver.

• Composition: This libnpurt.a might combine a few .o files for memory management, interrupt handling, and command queue management.
• Advantage: The application developer links this single, lightweight library to access the NPU without the bloat of a full OS driver stack.

Using static libraries freezes the dependency version at compile time. The executable will always use the exact library code it was linked with, regardless of what versions are installed on the target system. This is critical for reproducible builds and long-term maintenance of NPU applications in production, ensuring that performance and behavior do not drift due to updated system libraries.

• Contrast with Dynamic Libraries: A system update that changes /usr/lib/libnpu.so could inadvertently break or alter the performance of all dynamically-linked applications.
• Best Practice: Version the static library archive (e.g., libaccelerator_v2.3.a) and treat it as a firm build artifact.

A shared library (e.g., .so on Linux, .dll on Windows) that is linked to an executable at runtime, not compile time. The library code exists as a separate file on the system and is loaded into memory when the program launches. This enables:

• Code Sharing: Multiple programs can use a single copy in memory.
• Easy Updates: The library can be updated without recompiling the main application.
• Reduced Binary Size: The executable file contains only references, not the library code itself. The trade-off is runtime dependency; the correct library version must be present on the target system.

The fundamental building block of a static library. An object file (e.g., .o or .obj) is the output of a compiler's translation of a single source file. It contains:

• Machine Code: The compiled instructions for the target architecture.
• Symbol Table: A list of defined symbols (functions, variables) and unresolved external references.
• Relocation Information: Instructions for the linker on how to adjust addresses when the final memory layout is known. A static library is essentially an archive (using tools like ar) of multiple object files, indexed for the linker to resolve symbols.

The system program (ld, lld) that performs the final stage of building an executable. It takes one or more object files and libraries and:

• Resolves Symbols: Matches function calls and variable references with their definitions.
• Relocates Code: Adjusts addresses based on the final memory layout.
• Combines Sections: Merges all .text (code) sections, .data (initialized data) sections, etc. For static libraries, the linker performs selective linking, pulling in only the object files from the archive that are needed to satisfy unresolved symbols, minimizing final binary bloat.

A low-level contract between separately compiled modules, including static libraries. The ABI defines:

• Calling Convention: How function arguments are passed (registers vs. stack), and how return values are handled.
• Data Representation: Size, alignment, and layout of data types (structs).
• Name Mangling: How compiler-generated symbol names are encoded in object files. For a static library to link successfully with an application, both must be compiled for the same target architecture and adhere to the same ABI. Mismatches cause linker errors.

A suite of tools (compiler, assembler, linker, binutils) that runs on a host system (e.g., x86) to build software for a different target system (e.g., an ARM-based NPU). When building a static library for an NPU:

• The cross-compiler generates object files with the target's instruction set.
• The cross-linker and archiver create the final static library file.
• The entire vendor toolchain (compiler, SDK libraries) must be used to ensure compatibility with the NPU's proprietary ISA and runtime expectations.

An executable or library file that contains machine code for multiple hardware architectures within a single file. This is a deployment strategy that contrasts with single-architecture static libraries. For example, a fat binary might contain:

• x86-64 code for CPU fallback.
• ARM NEON code for mobile CPUs.
• Proprietary NPU code for acceleration. The operating system's loader selects the appropriate architecture at runtime. This avoids the need to distribute and manage separate binary files for each platform, but increases the overall file size.