Kegem0

我尝试自己编译了相关的依赖，包括 protobuf-3.0.0 gmock-1.7.0-master gflags-2.1.2 leveldb-1.18 openssl-OpenSSL_1_1_1 放置在/usr/local/xxx下（为了防止之后依赖冲突，我分别各自建了一个文件夹，删除的时候会方便） 然后重新执行 sh config_brpc.sh --headers="/usr/local/gflags/include /usr/local/protobuf/include /usr/local/leveldb/include /usr/local/openssl/include" --libs="/usr/local/gflags/lib /usr/local/protobuf/lib /usr/local/leveldb/lib /usr/local/openssl/lib /usr/local/gflags/bin /usr/local/protobuf/bin /usr/local/openssl/bin" make -j6 依然报同样的错误

把gcc升级到了8.3.0，现在的异常看起来正常了些  应该是我使用的protobuf版本不兼容的问题，但是源码来说应该是有这个文件的，为何编译之后该文件丢失了？

> make构建的话，可以加上VERBOSE看看编译参数，看include path能不能找到这个头文件。比如make VERBOSE=1 -j6 感谢，我查看了自己编译的protobuf的include的文件，确实没有这个文件。

> 貌似 gcc 4.8.5 对 1.6.0 中 doubly_buffered_data.h 中模板支持有问题，可以考虑升级编译器或者使用 1.5.0 中的 doubly_buffered_data.h > > > 应该是我使用的protobuf版本不兼容的问题，但是源码来说应该是有这个文件的，为何编译之后该文件丢失了？ > > 更换编译器后有没有执行 clean 操作呢？ > > 可以看下这个基于 cmake 的编译情况，基本环境应该和你一致。 https://download.copr.fedorainfracloud.org/results/wasphin/brpc/epel-7-x86_64/06235181-brpc/builder-live.log.gz 感谢！ 我在社区看到有人遇到了这个问题，他在使用1.5.0之后解决了这个问题，我上午在公司的机器进行了尝试，但是还是一样卡在了这里。我的标题写了我尝试过1.5.0-release，但是似乎没用。 不过说起来，可能我的操作顺序有问题？我担心依赖冲突，因此开启了一个新的虚拟机（说真的我在个人的机器上，因为先用yum...

> 如果只是在 centos7 下试用 brpc 的话，也可以考虑从[这里](https://download.copr.fedorainfracloud.org/results/wasphin/brpc/epel-7-x86_64/06235181-brpc/) 下载安装 rpm 使用，应该会简单些。 感谢！不过公司可能有相关的需求，因为之后要基于brpc进行一些开发，不然我也不会纠结于centos7了，并且最好确定一个比较稳定的依赖版本集合。

继续做一个排列组合，我在自己的机器上，用centos默认yum install下载的依赖，并且直接将gcc升级到8.3.0，clean之后重新make，弹出来的错误是protobuf和gflags的undefined reference的问题，截取一段如下： /home/ym/apache-brpc-1.6.0-src/src/bvar/variable.cpp:920: undefined reference to `gflags::RegisterFlagValidator(std::__cxx11::basic_string const*, bool (*)(char const*, std::__cxx11::basic_string const&))' libbrpc.a(variable.o):/home/ym/apache-brpc-1.6.0-src/src/bvar/variable.cpp:925: more undefined references to `gflags::RegisterFlagValidator(std::__cxx11::basic_string const*, bool (*)(char const*, std::__cxx11::basic_string const&))' follow libbrpc.a(gflag.o): In function...

但是这么做显然不是一个很好的方案，这里其实最莫名其妙的问题是centos不支持gcc4.8.5直接编译，这个编译时的段错误有点莫名其妙了。因此我们不得不提高gcc的版本，我选择了8.3.0，而且很明显的一点，后面也出现了，旧版本的libstdc++.so.6根本不足以提供项目代码所有的需求，我看文件他应该是用的libstdc++.so.6.0.19，而我们gcc8.3.0用的是libstdc++.so.6.0.25，所以不管怎么说，这个动态链接库是肯定需要升级的。 之后的确没有段错误了，但是因为yum install默认下载的依赖都是旧的gcc编译的，而我们用高版本的gcc去编译brpc，就会导致ABI的不一致，因此我们需要给每个要用到这些依赖的MakeFile中指定-D_GLIBCXX_USE_CXX11_ABI=0。 因此最好还是找几个高并且稳定的版本，自己用gcc8.3.0编译用作依赖，这样这些问题就能避免， 当然，下午的时候我就尝试过自己用gcc 8.3.0去主动编译这些依赖了，问题也已经写在了上面。看来我对c++的理解还是过于浅薄，居然从来没想过头文件可能在编译的过程中不被打包，MakeFile一般不就是指定一下要编译哪些cpp文件吗，难道是因为要编译的cpp文件中并没有这个头文件的依赖，所以就没有打包进来？其实肯定不合乎情理，不然brcp引入这个头文件有啥意义，连相应的代码实现都没有被打包进来，所以我们肯定需要一个有意义的编译。而且protobuf写了的文件又不打包，是什么目的？估计还是我理解不到位。 顺带一提，如果我们要用brpc的CMake，它倒是不像config_brpc.sh --headers="/usr/include" --libs="/usr/lib64 /usr/bin" 可以指定依赖所在的路径，其通过find_path()，find_package()去找依赖，我现在有点难以把握，如果我们把包下载到一个指定位置这个方法能找到吗，而且centos通常有protobuf等的默认依赖，等会他先找到默认的又不好处理了，如果我们之后要形成一个大型项目，最终还是得依赖于cmake，还是先好好学习一下CMake吧

> 把gcc升级到了8.3.0，现在的异常看起来正常了些  应该是我使用的protobuf版本不兼容的问题，但是源码来说应该是有这个文件的，为何编译之后该文件丢失了？ 找到问题的根源了，需要先执行yum install zlib-devel，以及yum update zlib protobuf执行./configure的时候会进行一些依赖的check，比如他会check zlib的版本。但是，之后的编译不会出问题，而是直接丢弃一些相关的头文件，继续编译。 但是brpc偏偏需要这些头文件，所以导致brpc的编译出错，如果不是在protobuf的issue上看到有人提了一嘴我估计这个问题是一辈子找不出来。