使用接口规避库依赖问题及链接顺序相关技术确认

Great question—let’s unpack this thoroughly to clear up all your confusion.

1. 核心说法是否正确？ #

Yes, the claim holds true for specific "interface-only" dependency scenarios, but we need to split this into static and dynamic linking contexts to be precise:

静态链接场景 #

If libB.a only depends on the interface of libA.a (e.g., in C++, libB uses pure virtual base classes from libA, or interacts with libA via function pointers/dynamic dispatch), then the linking order -lB -lA vs -lA -lB doesn’t matter. Here’s why:

• When libB is built against libA’s interface, its object files don’t contain direct references to libA’s concrete symbols (like function implementations or non-virtual methods). The only things libB needs are the symbol declarations (from headers) to compile, not the actual machine code.
• The linker only cares about resolving undefined symbols during static linking. Since libB has no undefined symbols pointing to libA’s concrete code, it doesn’t need libA to be present in the link order at all—let alone in a specific position.

动态链接场景 #

This logic becomes even more straightforward here:

• If libB.so relies on libA’s interface (again, abstract classes, function pointers), compiling and linking libB.so only requires libA’s headers. You don’t even need to link against libA.so during the build of libB.so because there are no concrete symbols to resolve.
• At runtime, the program using libB.so just needs to load the concrete implementation of libA (e.g., a libA_impl.so that implements the interface), and the dynamic linker will resolve the dispatch at runtime.

2. 接口场景下链接顺序无关的特性依赖什么？ #

This behavior depends on a combination of language semantics and linker implementation:

• Language specs (like C++’s virtual function mechanism) define how interface-based dispatch works, ensuring that concrete symbol references are deferred to runtime.
• The linker’s behavior is what makes the order irrelevant: since there are no unresolved symbols from libA in libB, the linker doesn’t need to search libA to fill gaps in libB’s code. This is a standard behavior across most modern linkers (GNU ld, clang lld, MSVC link.exe).

3. 无实际机器码时，libA的对象如何创建？ #

Ah, this is a key point to clarify: libB doesn’t create libA’s objects—some other part of the program does.

For example:

• libA defines an abstract interface class IService { virtual void doWork() = 0; };
• libB has a function void processService(IService* service) { service->doWork(); }—it only uses the interface, no concrete IService implementations.
• Your main program links against both libB and a concrete implementation (like libA_impl.a or libA_impl.so), which has class ConcreteService : public IService { ... };. The main program creates ConcreteService instances and passes them to libB’s processService function.

In this flow, libB never needs to know about ConcreteService’s machine code—it just interacts with the interface defined in libA’s headers. The concrete object creation happens outside libB, so libB doesn’t require libA’s implementation code at link time.

内容的提问来源于stack exchange，提问作者Kadir Erdem Demir