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检索目录中。

  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
  • 出错原因:增加了依赖库的路径,同时要指定连接的库
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版本不同。

  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 链接新版库

其实到这里,我才意识到json的部署有问题,然后跟换了新版的json,就能正常编译和运行了。

相关推荐
JunLan~2 小时前
Rocky Linux 系统安装/部署 Docker
linux·docker·容器
方竞3 小时前
Linux空口抓包方法
linux·空口抓包
sun0077004 小时前
ubuntu dpkg 删除安装包
运维·服务器·ubuntu
海岛日记4 小时前
centos一键卸载docker脚本
linux·docker·centos
oi774 小时前
使用itextpdf进行pdf模版填充中文文本时部分字不显示问题
java·服务器
AttackingLin4 小时前
2024强网杯--babyheap house of apple2解法
linux·开发语言·python
吃肉不能购5 小时前
Label-studio-ml-backend 和YOLOV8 YOLO11自动化标注,目标检测,实例分割,图像分类,关键点估计,视频跟踪
运维·yolo·自动化
学Linux的语莫5 小时前
Ansible使用简介和基础使用
linux·运维·服务器·nginx·云计算·ansible