glibc库版本低编译还报错?这个方法帮你解决
Glibc 包含了linux一些主要的C库,用于分配内存、搜索目录、打开关闭文件、读写文件、字串处理、模式匹配、数学计算等。
make工具
注意由于AW服务器make版本为3.8.1,在编译glibc高版本时候不兼容,所以需要更新make工具。假如服务器make版本较高,可以不用更新make工具。
网址 http://ftp.gnu.org/pub/gnu/make ,下载最新版本4.3。解压后,对make工具进行安装。进入make-4.3源码目录,执行以下命令。
# prefix 后面路径为make工具安装路径,这里我们指定安装到out目录下。 ./configure --prefix=${path} make make install
安装完成,我们看到make 4.3版本
glibc源码下载
网址 http://ftp.gnu.org/pub/gnu/glibc/ ,下载所需的glibc版本,注意gcc工具链版本和glibc版本需要匹配。
如下图所示是准备好编译脚本env. sh,glibc各个版本源码。
env.sh是把所有编译步骤整合在一起的脚本,可以根据具体情况单独执行每条指令。
打开脚本env.sh脚本。第4行是gcc位置,第5行是make工具位置(不需要安装高版本make可以去掉),第7行是glibc版本,第12行是glibc源码路径,第13行是glibc生成库文件路径,第14行是glibc编译过程产生中间文件存放路径,第16行是修改环境变量,使用我们自己的make和gcc工具。第30-33行,用于编译glibc。
其中31行 --host=arm-none-linux-gnueabihf ,host填入值要和gcc匹配 ,否则会出差。
运行env.sh脚本
./env.sh
注意下信息,我们可以看到glibc生成准备环境时候,已经使用了我们指定gcc工具链,make工具。
编译完成后,我们看到对应so库
替换glibc,例如在我们测试demo,修改Makefile,指定到我们glibc版本路径即可
重新编译,查看对应执行文件,看到已经使用对应版本版本glibc库
strings main | grep glibc
版本匹配问题
1、gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabi版本,glibc 2.29以下版本都可以编译通过
2、gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf版本,目前只在glibc 2.33编译通过,其他版本需测试。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一次网络请求中的流量分发过程 | 京东云技术团队
1. 摘要 现代的企业级或互联网系统往往需要进行流量规划,达成透明多级分流。流量从客户端发出到服务端处理这个过程里,流经的与功能无关的技术部件有(达成“透明分流”这个目标所采用的工具与手段):客户端缓存、域名服务器、传输链路、内容分发网络、负载均衡器、服务端缓存。透明分流带来的价值:高可用架构、高并发。 本文主要介绍流量规划中的网络请求过程过程及: 第一部分:对一次网络请求的过程作简要介绍,然后介绍自己目前了解到的前端网络组件搭配方式、后端网络组件搭配方式 第二部分:介绍LB负载系统 、vip与rip 的映射关系 第三部分:介绍内网域名解析及公网域名解析 2. 网络请求过程 通用请求过程及请求过程名词解释来源于: https://cf.jd.com/pages/viewpage.action?pageId=766717554 2.1 通用请求过程 2.2 请求过程名词解释 rip: 真实ip,指虚拟机或容器ip vip: 虚拟ip,不可跨机房,online申请,负载、自动探活等功能,分公网vip与内网vip 内网: 专指机房内部,严格的防火墙策略,内网之间无防火墙,可申请内网vip 提...
- 下一篇
BFF层聚合查询服务异步改造及治理实践 | 京东云技术团队
首先感谢王晓老师的[接口优化的常见方案实战总结]一文总结,恰巧最近在对稳健理财BFF层聚合查询服务优化治理,针对文章内的串行改并行章节进行展开,分享下实践经验,主要涉及原同步改异步的过程、全异步化后衍生的问题以及治理方面的思考与改进。 希望通过分享这些经验,能够对大家的工作有所启发和帮助。如果有任何问题或建议,请随时提出。 一、问题背景 将不同理财产品(如基金、券商、保险、银行理财等)针对不同投放渠道人群进行个性化商品推荐,每个渠道或人群看到的商品或特性数据又各不相同,为方便渠道快速对接,由BFF层统一对所有数据进行聚合下发,因此BFF层聚集依赖了大量底层原子服务,所以主要问题是在依赖大量上游接口的场景下保障TP99、以及可用率。 案例: 以其中比较典型的商品推荐接口为例,需要依赖本地商品池缓存、算法推荐服务、商品基础信息服务、持仓查询服务、人群标签服务、券配置服务,可领用券服务、其他数据服务ServN……等等,其中大部分上游原子接口对单次批量查询支持有限,所以极端情况,单个推品接口单次推荐1-n个推品,每个商品如果要绑定10个动态属性,至少需要发起(1~n)*10次io调用。 改造前...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G