文章目录
- 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文件夹
// 找不到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,就能正常编译和运行了。