add_library(name shared ...)足够生成动态库，因shared是cmake内置关键字（≥2.6即支持），无需额外安装或配置；平台自动补全前缀后缀，构建失败多因源文件路径错误。
直接用 add_library 指定 SHARED 就能生成动态库，不需要额外“安装” CMake 后再配置什么环境变量或插件。
为什么 add_library(name SHARED ...) 就够了
CMake 本身不区分“安装后才能用动态库功能”——SHARED 是内置关键字，只要 CMake 版本 ≥ 2.6（远早于当前所有常用版本），该语法就可用。关键不是 CMake 装没装好，而是你是否在 CMakeLists.txt 中正确声明、并确保构建系统支持动态链接（Linux/macOS 默认支持；Windows 需有 MSVC 或 MinGW 工具链）。
-
add_library(calc SHARED src/add.cpp src/sub.cpp)会生成libcalc.so（Linux）、libcalc.dylib（macOS）或calc.dll（Windows） - 库名前缀和后缀由平台自动补全，你只需写
calc，不用写libcalc.so - 如果构建失败报错 “no rule to make target”，大概率是源文件路径不对，或
src/下实际没有对应.cpp文件
SHARED 和 STATIC 能不能共存一个项目
可以，而且很常见：同一组源码同时产出 .so 和 .a，供不同场景链接。但要注意命名冲突和符号导出问题。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须用不同目标名，例如：
add_library(calc_static STATIC ${SRC})和add_library(calc_shared SHARED ${SRC}) - 若源码中有 Windows DLL 导出宏（如
__declspec(dllexport)），建议只在SHARED目标上定义BUILD_DLL，静态库目标不要加——否则可能触发编译警告甚至链接失败 - Linux/macOS 下通常无需导出宏，但若头文件里写了条件编译逻辑（比如用
__attribute__((visibility("default")))），也要确保只对SHARED生效
生成的动态库找不到或运行时报 libxxx.so: cannot open shared object file
这不是 CMake 生成阶段的问题，而是运行时链接器找不到路径。CMake 只管编译生成，不负责部署。
- Linux 下临时解决：运行前执行
export LD_LIBRARY_PATH=$PWD/lib:$LD_LIBRARY_PATH（假设库在./lib） - 更可靠的做法是在
CMakeLists.txt中设置 RPATH：set_target_properties(calc_shared PROPERTIES INSTALL_RPATH "$ORIGIN")，这样生成的二进制会记录“去同目录找库” - 别依赖
set(LIBRARY_OUTPUT_PATH ...)——它只影响构建时输出位置，不影响运行时行为；真正起作用的是INSTALL+install(TARGETS ... LIBRARY DESTINATION ...)配合make install
最容易被忽略的一点：动态库的 ABI 兼容性不体现在 CMake 配置里，而取决于你是否启用了 -fPIC（Linux/macOS）或是否在 Windows 上用了正确的导出方式。CMake 默认为 SHARED 自动加 -fPIC，但如果你手动覆写了 CMAKE_CXX_FLAGS 并删掉了它，就会静默失败——链接时可能不报错，运行时却崩溃。
