Openssl数据安全传输平台017：Linux客户端代码的编译与调试-Bug记录
文章目录
- 1 在windows上先预编译
- 2 Centos上进入项目文件夹进行编译
-
- 2.0 `最终的编译指令`
- 2.1 找不到lprotobuf，找不到protobuf的google文件夹
-
- 2.1.1 编译指令及提示
- 2.1.2 问题分析
- 2.1.3 解决办法
- 2.2 json类中方法unreference
-
- 2.2.1 编译指令及提示
- 2.2.2 问题分析
- *** 最终的编译指令，客户端启动成功
- 2.3 ----------由版本不兼容导致-找不到动态库ljson - 旧版本的其他问题
- 2.4---------- 动态库软链接失效
- 2.5 ----------undefined reference to `Json::Value::asString[abi:cxx11]() const
1 在windows上先预编译
除了找不到库和目录的问题，其他的都应该在windows上解决。这个时候客户端代码在widows上编译，除了protobuf找不到目录，其他的基本没有什么问题。
然后打开虚拟机，项目文件已经在/home/projects目录下了
2 Centos上进入项目文件夹进行编译
2.0 最终的编译指令
g++ *.cpp *.cc -lpthread -ljsoncpp -lprotobuf -lcrypto -locci -lclntsh -std=c++11
2.1 找不到lprotobuf，找不到protobuf的google文件夹
-
2.1.1 编译指令及提示
// 找不到protobuf
g++ *.cpp *.cc -ljson -lpthread -lprotobuf -lcrypto -locci -lclntsh -std=c++11
2.1.2 问题分析
protobuf部署的时候，这个文件夹我安装的时候，是把windows下编译的库直接放在了centos的下面这个路径，执行文件、库、google文件夹都没整理。
后来我才明白，Windows下的动态库是.dll，Linux上的是.so，两者不通用。Linux环境下需要重新在Linux环境中编译源码。
2.1.3 解决办法
在Linux上重新部署Protobuf，参考如下（重写了一遍）
Openssl数据安全传输平台003：Protobuf3.17.2 - 部署 - Windows/ Centos8：
https://blog.csdn.net/jiangchufeng123/article/details/133918080
再次编译，跟protobuf和google文件夹相关的bug就消除了
2.2 json类中方法unreference
2.2.1 编译指令及提示
2.2.2 问题分析
这个bug我找了很久，后来发现是因为json版本跟centos上gcc版本和代码格式不兼容导致的。
代码使用的json新版解析风格，但是部署json的时候参考的黑马教学视频用的旧版。
我甚至一度以为json和jsoncpp是两个不同的库。直到睡了一觉醒来，觉得不对劲，json就是一个东西，不可能有两个动态库。后面在编译指令中去除了老版本的json库，系统中删除了老版本的动态库文件，重新编译就好了。
相应的，我也修改了json的部署教程。
Openssl数据安全传输平台010：jasoncpp 1.9.5编译及常用API-
Windows/Centos8-含测试代码：
·
https://blog.csdn.net/jiangchufeng123/article/details/134024850
然后重写Json部署教程的时候，在官网看到了说明…0.10.X的版本不能使用C++11…
*** 最终的编译指令，客户端启动成功
g++ *.cpp *.cc -lpthread -ljsoncpp -lprotobuf -lcrypto -locci -lclntsh -std=c++11
2.3 ----------由版本不兼容导致-找不到动态库ljson - 旧版本的其他问题
/以下仅用作排除bug的参考，并不能解决实际问题/
- 分析
通常在软件编译时出现的usr/bin/ld: cannot find -lxxx的错误，主要的原因是库文件并没有导入的ld检索目录中。
确认库文件是否存在，比如-l123, 在/usr/lib/usr/local/lib,或者其他自定义的lib下有无lib123.so, 如果只是存在lib123.so.1，那么可以通过ln -sv lib123.so.1 lib123.so，建立一个连接重建lib123.so.
检查/etc/ld.so.conf中的库文件路径是否正确，如果库文件不是使用系统路径，/usr/lib, /usr/local/lib,那么必须在文件中加入。
ldconfig重建ld.so.cache文件，ld的库文件检索目录存放文件。尤其刚刚编译安装的软件，必须运行ldconfig，才能将新安装的
- 重新编译还是不对，因为我把库改成了依赖库的路径
-L/usr/include/json，其实就是这里少加了个-ljson。 - 出错原因：
增加了依赖库的路径，同时要指定连接的库。
// 增加了依赖库路径和库
g++ *.cpp *.cc -L/usr/include/json -ljson -lpthread -lcrypto -lprotobuf -locci -lclntsh -std=c++11
2.4---------- 动态库软链接失效
在处理2.1 这个问题的时候还出现了个小错误，创建动态库的链接文件失效了，我到Centos里面直接找到了这个链接查看properties的时候，发现显示broken。
于是我用root用户删除libjson.so，然后又重新链接了一次：ln -s /lib/libjson_linux-gcc-11_libmt.so /lib/libjson.so，然后再次使用上述命令，bug就少了几个。
2.5 ----------undefined reference to `Json::Value::asStringabi:cxx11 const
一般出现cxx11 const’ 应该都是gcc的版本不一样。 我遇到的情况是jsoncpp生成的动态库和依赖它而生成的动态库的gcc版本不同。
GCC5.1发布时，为libstdc++添加了新的特性，旧版就无法兼容了。为了避免混乱，对于旧版而言，有旧版(c++03规范)的libstdc++.so。也就是说有两个库，旧版(c++03规范)的libstdc++.so和新版(c++11规范)的libstdc++.so同时存在。
为了避免两个库到底选择哪一个的麻烦，GCC5.1就引入了
-D_GLIBCXX_USE_CXX11_ABI来控制编译器到底链接哪一个libstdc++.so，
-D_GLIBCXX_USE_CXX11_ABI=0 链接旧版库
-D_GLIBCXX_USE_CXX11_ABI=1 链接新版库
其实到这里，我才意识到json的部署有问题，然后跟换了新版的json，就能正常编译和运行了。