交叉编译qt5.9,编译tslib出现问题

weixin_38052782 2019-09-19 11:59:53
交叉编译qt5.9 配置选项中添加-tslib时 报错误: ERROR: Feature 'tslib' was enabled, but the pre-condition 'libs.tslib' failed.基本上是同样的方法,编译qt5.7就没有报这个问题,请问原因有解决办法吗
...全文
3314 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
BG2DEF 2020-10-16
  • 打赏
  • 举报
回复
我也出现了这个问题,你试试看用file指令查看编译出来的tslib是不是arm架构的吧
我之前用错了编译器导致编译出来是x86的所以出现了这个问题,重新指定交叉编译器之后就解决了
MDZ2006 2020-08-20
  • 打赏
  • 举报
回复
我也遇到了这个问题,qt版本是5.9.9与5.14.0都报这个错。
MDZ2006 2020-08-20
  • 打赏
  • 举报
回复
我也遇到了同样的问题,qt5.9.9跟qt5.14.0都有同样的问题
MDZ2006 2020-08-20
  • 打赏
  • 举报
回复 1
在网上找了好几天都没找到答案,最后自己摸索着解决了。
找到原因了,如果你的交叉编译工具链为arm-linux-gnueabihf,那么你编译tslib时,配置的时候注意./configure --host=arm-linux-gnueabihf --prefix=/home/work/lib/tslib。即host=arm-linux-gnueabihf 而不是arm-linux就可以了。
weixin_38062043 2019-09-19
  • 打赏
  • 举报
回复
你的解决了吗?我也有这样的问题
内容概要:本文详细介绍如何通过搭建ELK(Elasticsearch、Logstash、Filebeat、Kibana)日志分析系统,实现对大模型Token中转服务的全链路可观测性管理。系统能够实时追踪每次API调用的性能指标(如首包耗时、总耗时)、Token消耗、费用核算、用户行为及异常请求,解决自建中转服务长期存在的“黑盒”问题,包括费用不清、性能瓶颈难定位、恶意刷量难识别等痛点。文章提供完整的日志结构设计、ELK组件配置方案(可直接复制部署)以及Kibana五大核心可视化看板,覆盖从数据采集、清洗、存储到展示的全流程,适用于个人、团队或企业级AI网关场景。; 适合人群:具备一定运维与开发能力的技术人员,如AI中台工程师、DevOps、私有化部署开发者及企业AI基础设施负责人,尤其适合运营Token代理、模型中转服务的团队; 使用场景及目标:① 实现API调用的精准费用分摊与成本控制;② 定位性能瓶颈与慢请求根源;③ 识别恶意刷量与异常调用行为;④ 构建可审计、可告警、可复盘的生产级可观测体系; 阅读建议:此资源强调结构化日志输出与业务字段定义的重要性,建议读者结合自身中转服务架构,严格按照JSON日志模板实施,并完整配置ELK链路以发挥最大效能,同时关注文中避坑指南以保障系统稳定运行。

477

社区成员

发帖
与我相关
我的任务
社区描述
其他技术讨论专区
其他 技术论坛(原bbs)
社区管理员
  • 其他技术讨论专区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧