动态链接库程序体积过大及ld递归依赖链接要求的技术咨询

Great questions—let's unpack them both, keeping your cross-compiling and mixed static/dynamic linking setup front and center, since that's key to understanding what's happening.

Question 1: Why does ld require linking all recursive dynamic dependencies? #

First, let's set the baseline for how dynamic linking usually works: on most systems (like Linux), when you link directly against a dynamic library, that library's own dependencies are stored in its DT_NEEDED metadata section. At runtime, the dynamic linker (ld.so) uses these entries to automatically find and load all recursive dependencies without you having to list them explicitly during the linking step.

But your scenario has a critical twist: your large program uses static linking for all its internal modules, with only some external libraries linked dynamically. Here's why you're being forced to list every recursive dependency:

• Static modules don't track dependencies: Unlike dynamic libraries, static libraries (or the statically linked modules in your program) are just bundles of object files with no built-in metadata about their downstream dependencies. When you link your static code against a dynamic library, ld needs to resolve every symbol referenced in your static modules—including those that live in the recursive dependencies of your direct dynamic library. If you skip those recursive libraries, ld can't find the required symbols and throws an error.
• Cross-compiling toolchain quirks: Cross-compiling toolchains often have stricter default linker rules than native ones. Some may disable automatic dependency resolution for dynamic libraries by default, or fail to properly parse DT_NEEDED entries from cross-built dynamic libraries, forcing you to manually specify all transitive dependencies.
• Linker flags like --no-as-needed: If your CMake setup is passing the --no-as-needed flag to ld, the linker won't automatically follow the dependencies of the libraries you list. Instead, it expects you to explicitly add every library that contributes a symbol used by your code—including recursive ones.

Question 2: Why is the program still so large when using dynamic libraries? #

Dynamic linking doesn't magically shrink executable size—especially not in your setup where most of the code is statically linked. Here's why your binary is still bulky:

• Your core code is statically linked: The vast majority of your program's size comes from its own internal modules, which are all statically linked into the final executable. Dynamic linking only removes the external libraries you're linking dynamically from the binary size. If those external libs are a small fraction of the total code, you won't see a meaningful reduction. For example, if your static modules make up 90% of the total size, switching a few external libs to dynamic won't move the needle much.
• Unstripped debug symbols: If you're building a development version without stripping debug symbols, the executable will be drastically larger. Debug info for your static modules is embedded directly in the binary, and dynamic libraries don't affect this. Try running strip on the final executable to see if this is a major factor.
• Unoptimized builds: If you haven't enabled compiler optimizations (like -O2 or -O3), the generated code will be much bulkier. Optimizations remove dead code, inline small functions, and shrink the overall size—and this applies to your static modules, which are the bulk of your program.
• Accidental static linking: In cross-compiling setups, CMake sometimes falls back to static library versions (.a files) if it can't find the dynamic ones (.so). Double-check your CMake logs to confirm that the libraries you intend to link dynamically are indeed being pulled in as dynamic archives.
• Embedded resources: If your program includes large assets (like images, configs, or data files) directly in the executable (via tools like objcopy), those will bloat the size regardless of linking type.

内容的提问来源于stack exchange，提问作者errolflynn