Openssl数据安全传输平台017：Linux客户端代码的编译与调试-Bug记录

文章目录

[1 在windows上先预编译](#1 在windows上先预编译)
[2 Centos上进入项目文件夹进行编译](#2 Centos上进入项目文件夹进行编译)
- [2.0 `最终的编译指令`](#2.0 最终的编译指令)
- [2.1 找不到lprotobuf，找不到protobuf的google文件夹](#2.1 找不到lprotobuf，找不到protobuf的google文件夹)
- - [2.1.1 编译指令及提示](#2.1.1 编译指令及提示)
  - [2.1.2 问题分析](#2.1.2 问题分析)
  - [2.1.3 解决办法](#2.1.3 解决办法)
- [2.2 json类中方法unreference](#2.2 json类中方法unreference)
- - [2.2.1 编译指令及提示](#2.2.1 编译指令及提示)
  - [2.2.2 问题分析](#2.2.2 问题分析)
- [*** 最终的编译指令，客户端启动成功](#*** 最终的编译指令，客户端启动成功)
- [2.3 ----------由版本不兼容导致-找不到动态库ljson - 旧版本的其他问题](#2.3 ----------由版本不兼容导致-找不到动态库ljson - 旧版本的其他问题)
- [2.4---------- 动态库软链接失效](#2.4---------- 动态库软链接失效)
- [2.5 ----------undefined reference to `Json::Value::asString[abi:cxx11]() const](#2.5 ----------undefined reference to `Json::Value::asStringabi: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 编译指令及提示

python 复制代码

// 找不到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...

*** 最终的编译指令，客户端启动成功

cpp 复制代码

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。
出错原因：增加了依赖库的路径，同时要指定连接的库。

cpp 复制代码

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

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，就能正常编译和运行了。