Kegem0 commented on issue #2356: URL: https://github.com/apache/brpc/issues/2356#issuecomment-1675210269
但是这么做显然不是一个很好的方案，这里其实最莫名其妙的问题是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吧 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
