undefined symbol: _ZN5boost15program_options22error_with_option

log: undefined symbol: _ZN5boost15program_options22error_with_option_name15set_option_nameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

这种报错都是因为 编译链接阶段 和 运行阶段 看到的lib不一致导致的。

root cause:

1. 编译阶段用了 -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.

2. 在运行阶段，于是就报错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目录下是存在的，也就避免了上面这一系列的问题。