Alright, let's break down the symbol resolution issues you're hitting when building a library that supports both static and dynamic linking—this is such a common pain point, so you’re definitely not alone here. Below are the most frequent problems and practical fixes to get your three-project setup (exe, static .lib, dynamic .dll) working smoothly:

1. Messed-Up Export/Import Macros #

This is the #1 culprit. Static libraries don’t need symbol exports, but dynamic libraries require explicit marking of symbols that should be accessible to external code. The catch is: if your exe links the static library, using DLL export/import macros can accidentally mark symbols as dllimport, leading to missing symbol errors.

Fix:

• Define a conditional macro to toggle between export/import/empty based on the build target:

  #ifdef MYLIB_BUILD_DLL
  #define MYLIB_API __declspec(dllexport)
  #elif defined(MYLIB_USE_DLL)
  #define MYLIB_API __declspec(dllimport)
  #else
  #define MYLIB_API // Empty for static library builds
  #endif
  

• Add this macro to all public classes/functions in your library’s header files:

  class MYLIB_API MyPublicClass {
      // Class implementation here
  };
  
  MYLIB_API void MyPublicUtilityFunction();
  

• Configure your projects:
  • For the dynamic library project: Add MYLIB_BUILD_DLL as a preprocessor definition.
  • For the exe project: Add MYLIB_USE_DLL if linking the dynamic library’s import .lib; leave it out if linking the static .lib.

2. Multiple Definition Errors #

If your exe links both the static and dynamic libraries, or if the two libraries share identical symbol names, you’ll hit "multiply defined symbols" errors.

Fixes:

• Isolate symbols: Use anonymous namespaces in C++ or static for C functions in the static library to restrict symbol visibility to the library itself (only do this if the static library’s symbols don’t need to be called directly by the exe).
• Strict dependency control: Never link both the static .lib and dynamic import .lib in the same exe build. Pick one and stick to it.

3. Linker Can’t Find Symbols (Unresolved External Errors) #

This often boils down to missing dependencies or incorrect link order (more of an issue with GCC than MSVC, but still possible in both).

Fixes:

• MSVC: Double-check the exe’s linker input settings—make sure the correct .lib (static or dynamic import) is added. For static libraries, ensure all dependent libraries (if any) are also linked in the exe project. For dynamic libraries, just the import .lib is needed (the .dll will be loaded at runtime).
• GCC: Follow the "dependency order" rule: link the static library after your exe’s object files. Example command:

  g++ main.o -o my_app -lmylib_static
  

4. Unresolved Symbols in Static Libraries #

Static libraries don’t resolve their own dependencies during compilation—this happens only when the exe links the static library. If your static library relies on another library (static or dynamic), the exe must link that dependency too.

Fix:

• Map out your library’s dependency chain, then add all required dependent libraries to the exe’s linker inputs. If the static library depends on a dynamic library, link the dynamic library’s import .lib in the exe and ensure the .dll is available at runtime.

Quick Troubleshooting Checklist #

• Verify your export macro is correctly set up for each build target.
• Look closely at the linker error’s symbol name—does it match a public symbol in your library? Is it marked with the right import/export attribute?
• Confirm your exe isn’t accidentally linking both static and dynamic library variants.

If you can share the exact linker error messages (like the full text of LNK2019 or LNK1169 errors), I can help you narrow down the issue even faster!

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