现打算基于nebula 2.5做内部版本开发，需要集成依赖一些公司内部公共库，发现一些依赖冲突问题主要是openssl，nebula third-party/lib64/libssl.a openssl 1.1.x，公司第三方依赖1.0.x openssl 动态库，想请教下：
1、nebula 2.x 依赖的哪些third-party 必须依赖openssl 1.1.x 版本？
2、从nebula 1.x的工程里找到thirdparty fbthrift.cmake、wangle.cmake 依赖lib64/libssl.a openssl，nebula2.x的common工程里没找到thirdparty 的版本信息，请问nebula 2.x和nebula1.x的thirdparty 依赖是否没有变化
3、我们内部开发时降openssl版本是否可行？
你可以研究一下nebula-third-party这个仓库里面的编译依赖关系。具体能不能降看其他依赖了，以实际测试验证为准。
1 个赞
直接降低openssl版本的可能性不大，原因在于1.1.0版本的openssl的数据结构、api都有了较大变化具体参见：openssl 1.1.0 changelog
如果一定要降低openssl的版本，基本逃不掉要对依赖openssl的部分作修改了。
1 个赞
感谢回复~，正在考虑研究third-party的编译依赖问题，在common 仓库里没找到，原来单独有个仓库nebula-third-party
嗯，加入其他公共库的依赖后编译，发现openssl1.0 与1.1 冲突严重，完全不兼容，就想研究下nebula-third-party 具体依赖openssl的库看看。依赖openssl的主要是folly，wangle，fbthrift，看是否一定需要依赖openssl1.1，fbthrift github上 system dependencies 写的opensslv1.0.2，所以想搞清楚哪些第三方库是必须要依赖openssl1.1，核心库像folly,fbthrift等不必须依赖的话，可以想办法解决一下
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。