undefined symbol: _ZN5boost15program_options22error_with_option
log: undefined symbol: _ZN5boost15program_options22error_with_option_name15set_option_nameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
这种报错都是因为 编译链接阶段 和 运行阶段 看到的lib不一致导致的。
root cause:
- 编译阶段用了 -I(大写的i)/xxx/boost/boost-1.80.0版本的boost库，并且 -L/xxx/boost/boost-1.80.0/linuxlib, -l(小写的L)boost_program_options。这个地方的问题在于:
- /xxx/boost/boost-1.80.0 目录下，只有 boost_program_options.a, 没有对应的 .so。并且/xxx/boost/boost-1.80.0/linuxlib不在LD_LIBRARY_PATH列表里（当然在列表里也没有用，因为没有对应的.so）。
- 在系统的默认搜索路径/lib64目录下，找到了 boost_program_options.so，于是编译出来的 out.so 就认为自己需要/lib64目录下的boost_program_options.so（这是当ldd out.so的时候，其输出显示其依赖一个低版本的boost的原因）。
- gcc manual明确说了优先使用 .so, 参考这里
-l library
If both static and shared libraries are
found, the linker gives preference to linking with the shared library unless the
-static option is used.
- 在运行阶段，于是就报错undefined symbol
解决方法：
法1：很简单，找一个1.80.0版本的boost_program_options.so，把其路径加到LD_LIBRARY_PATH里。
法2：链接阶段如果想使用.a的时候，不需要-L/-l, 直接在link阶段，像加一个 .o 那样，直接 g++ file1.o file2.o /xx/boost_program_options.a 去显示的使用 .a
总结：
系统的默认搜索路径/lib64下有一个boost_program_options.so是原罪，如果没有的话，在链接阶段-L/-l的时候，因为没有找到libboost_program_options.so, 所以会去转而使用boost_program_options.a, 这个 .a文件在/xxx/boost/boost-1.80.0目录下是存在的，也就避免了上面这一系列的问题。