1 在windows上先预编译

除了找不到库和目录的问题，其他的都应该在windows上解决。这个时候客户端代码在widows上编译，除了protobuf找不到目录，其他的基本没有什么问题。

然后打开虚拟机，项目文件已经在/home/projects目录下了

2 Centos上进入项目文件夹进行编译

2.1 找不到protobuf的google文件夹

• 编译指令如下

// 找不到protobuf

g++ *.cpp *.cc -ljson -lpthread -lprotobuf -lcrypto -locci -lclntsh -std=c++11

• 解决办法
  protobuf部署的时候，这个文件夹我安装的时候，是放在了centos的下面这个路径，执行文件、库、google文件夹都没整理。

/usr/local/protobuf/include

然后我去调整了下protobuf的位置，最终protobuf的部署，参考下面的文章，然后这个问题得到了解决。

2.2 找不到动态库ljson

//第二次

g++ *.cpp *.cc -ljson -lpthread -lprotobuf -lcrypto -L/usr/local/protobuf/include -locci -lclntsh -std=c++11

• 分析

通常在软件编译时出现的usr/bin/ld: cannot find -lxxx的错误，主要的原因是库文件并没有导入的ld检索目录中。

1. 确认库文件是否存在，比如-l123, 在/usr/lib/usr/local/lib,或者其他自定义的lib下有无lib123.so, 如果只是存在lib123.so.1，那么可以通过ln -sv lib123.so.1 lib123.so，建立一个连接重建lib123.so.

2. 检查/etc/ld.so.conf中的库文件路径是否正确，如果库文件不是使用系统路径，/usr/lib, /usr/local/lib,那么必须在文件中加入。

3. ldconfig重建ld.so.cache文件，ld的库文件检索目录存放文件。尤其刚刚编译安装的软件，必须运行ldconfig，才能将新安装的

• 重新编译还是不对，因为我把库改成了依赖库的路径-L/usr/include/json，其实就是这里少加了个-ljson。
• 出错原因：增加了依赖库的路径，同时要指定连接的库。

// 增加了依赖库路径和库

g++ *.cpp *.cc -L/usr/include/json -ljson -lpthread -lcrypto -L/usr/local/protobuf/include -lprotobuf -locci -lclntsh -std=c++11

2.3 动态库软链接失效

但是在处理这个问题的时候还出现了个小错误，创建动态库的链接文件失效了，我到Centos里面直接找到了这个链接查看properties的时候，发现显示broken。

于是我用root用户删除libjson.so，然后又重新链接了一次：ln -s /lib/libjson_linux-gcc-11_libmt.so /lib/libjson.so，然后再次使用上述命令，bug就少了几个。

g++ *.cpp *.cc -lpthread -L/usr/include/json -ljson -L/usr/local/protobuf/lib -lprotobuf -lcrypto -locci -lclntsh -std=c++11

2.4 undefined reference to `Json::Value::asStringabi:cxx11 const

一般出现cxx11 const’ 应该都是gcc的版本不一样。 我遇到的情况是jsoncpp生成的动态库和依赖它而生成的动态库的gcc版本不同。

1. GCC5.1发布时，为libstdc++添加了新的特性，旧版就无法兼容了。为了避免混乱，对于旧版而言，有旧版(c++03规范)的libstdc++.so。也就是说有两个库，旧版(c++03规范)的libstdc++.so和新版(c++11规范)的libstdc++.so同时存在。

2. 为了避免两个库到底选择哪一个的麻烦，GCC5.1就引入了-D_GLIBCXX_USE_CXX11_ABI来控制编译器到底链接哪一个libstdc++.so，

-D_GLIBCXX_USE_CXX11_ABI=0 链接旧版库
-D_GLIBCXX_USE_CXX11_ABI=1 链接新版库

问题出在客户端ClientOP上，在头文件上添加#define _GLIBCXX_USE_CXX11_ABI 0