stacktrace_from_exception on non-x86

未关闭

#163 创建于 2024年4月29日 7 条评论 0 个 reaction 已指派 0 人在 GitHub 查看

还没有人认领这个 Issue。

评估

难度: 4/5
预计耗时: 3-5 天
新手友好度: 35/100

Issue 类型: 缺陷
描述清晰度: 基本清楚
活跃度: 停滞
技术栈: cpp
领域: devtools

调研方向

使用 issue 中的 bootstrap.sh 和 b2 命令复现 non-x86 构建。阅读 src/exception_headers.h 和 src/from_exception.cpp，包括 is_libcpp_runtime，以跟踪架构和运行时检查。完成标准是 stacktrace library 能够在 non-x86 上使用 GCC/libstdc++ 构建，而不需要所列出的变通方案。

由索引模型根据 Issue 内容生成。

描述

enhancement help wanted

I submitted the below to the mailing list, but I wanted to re-iterate it here for more eyes. https://lists.boost.org/Archives/boost/2024/04/256604.php

This feature is guarded by BOOST_STACKTRACE_ALWAYS_STORE_IN_PADDING, but that is only enabled on x86.
This means that

./bootstrap.sh --with-toolset=gcc --with-libraries=stacktrace
./b2 install threading=multi toolset=gcc

always fails to build on non-x86 platforms. There are three current workarounds:

set boost.stacktrace.from_exception=off
set BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK
build with threading=single

(1) prevents me from using this feature. (2) shouldn't be needed on it's face because I'm using gcc/libstdc++. (3) affects more than stacktrace.

Is this an incidental error, or is there a reason I wasn't able to deduce as to why this feature can't be used on non-x86+libstdc++?

It seems like the check for libc++ on non-x86 can't be entirely done at compile time. I definitely understand wanting to alert users to the dangers of using this feature, but there also doesn't seem to be a good way of detecting the presence of libc++ at compile time (hence the need for is_libcpp_runtime).

主要语言: C++
星标: 497
派生: 86
平均合并: 8 天 20 小时
30 天内合并 PR: 3

贡献指南

这个仓库没有索引到贡献指南

从这里开始

先读完整个 Issue，再读项目的贡献指南。
在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
Fork 仓库，在一个分支上完成修改。
提交 Pull Request，并在描述里引用这个 Issue 编号。

boostorg/stacktrace 的其他 Issue

`std::formatter` specialization 未关闭

难度 4/5 3-5 天新手友好度 52/100

boostorg/stacktrace#233 · 2026年7月7日创建
Ошибка в Inscape 未关闭

难度 5/5 一周以上新手友好度 15/100

boostorg/stacktrace#211 · 1 条评论 · 2025年10月2日创建
`-static-libstdc++` with `stacktrace_from_exception` produces duplicate symbol `__cxa_allocate_exception` 未关闭

难度 4/5 3-5 天新手友好度 35/100

boostorg/stacktrace#208 · 6 条评论 · 2025年7月24日创建
The BOOST_STACKTRACE_HAS_BACKTRACE check doesn't seem to work with clang 未关闭

难度 3/5 1-2 天新手友好度 48/100

boostorg/stacktrace#197 · 3 条评论 · 2024年12月20日创建
Implementation with `libdwfl`? 未关闭

enhancement help wanted

难度 5/5 一周以上新手友好度 25/100

boostorg/stacktrace#176 · 1 条评论 · 2024年8月22日创建

查看 boostorg/stacktrace 的全部 Issue

相似的 Issue

An automatic array with a negative run-time extent has a negative size instead of zero 未关闭

难度 2/5 1-3 小时新手友好度 75/100

lfortran/lfortran#13475 · 2026年9月24日创建
Use ament_cmake_ros_core::ament_ros_defaults instead of setting CMAKE_C_STANDARD or CMAKE_CXX_STANDARD 未关闭

good first issue

难度 2/5 1-3 小时新手友好度 75/100

ros2/message_filters#338 · 2026年9月24日创建
Needs documentation update: Qt6 install or build instructions are not provided 未关闭

难度 2/5 1-3 小时新手友好度 70/100

subsurface/subsurface#4984 · 2026年9月24日创建
[Bug] Desktop: DataChannel onBufferedAmountLow / onBufferedAmountChange never fires — missing C++ OnBufferedAmountChange override 未关闭

难度 2/5 1-3 小时新手友好度 75/100

flutter-webrtc/flutter-webrtc#2206 · 2026年9月24日创建
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps 未关闭

难度 2/5 1-3 小时新手友好度 70/100

google-ai-edge/LiteRT-LM#3739 · 2026年9月24日创建

更多 C++ Issue