No supported way to negate `-pthread`: `USE_PTHREADS` is deprecated but is the only working off-switch
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 64/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- wasm
- Lĩnh vực
- compilers
Hướng nghiên cứu
Start with the user_settings handling in emcc.py and the LEGACY_SETTINGS entry in tools/settings.py, then reproduce the emsdk 6.0.9 commands from the issue. Determine how a supported negation of -pthread should interact with USE_PTHREADS and STRICT. Done means a thread-enabled command can be reliably disabled without the deprecated setting, or the documented workaround remains accepted under STRICT.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
USE_PTHREADS is deprecated in favour of -pthread, but -pthread has no negation, so a
project that consumes a build system which passes -pthread unconditionally has no
supported way to turn threads off. The only mechanism that works is the deprecated setting
itself, which is a hard error under STRICT.
I am filing because the deprecation message explicitly invites it ("Please open a bug if
you have a continuing need for this setting"), and a tracker search for -no-pthread,
for negating -pthread, and for the USE_PTHREADS deprecation turned up nothing similar.
What I tried, on emsdk 6.0.9
Baseline, matching what the upstream build passes:
emcc -pthread -sALLOW_MEMORY_GROWTH=1 -o out.js hello.c
# -> (import "env" "memory" (memory $mimport$0 256 32768 shared))
Then each candidate negation, injected via EMCC_CFLAGS so it lands after the
command line (the same shape a downstream build system leaves you with):
| Flag | Result |
|---|---|
-no-pthread |
still shared -- the string does not occur in emcc.py, tools/ or docs/emcc.txt; it is forwarded to clang, which reports it unused |
-sSHARED_MEMORY=0 |
still shared |
-sPTHREADS=0 |
hard error: PTHREADS is an internal setting and cannot be set from command line |
-sUSE_PTHREADS=0 |
works -- (memory $0 258 32768), non-shared, no PThread/Worker references in the glue |
emcc.py (around the user_settings handling) maps USE_PTHREADS onto the internal
PTHREADS, and that appears to be the only path that can negate it. tools/settings.py
lists USE_PTHREADS in LEGACY_SETTINGS with "No longer needed. Use -pthread instead",
and legacy settings are fatal when STRICT is on.
Why this matters downstream
We are building Lean 4 for WebAssembly. Its CMake sets
set(EMSCRIPTEN_SETTINGS "-s ALLOW_MEMORY_GROWTH=1 -fwasm-exceptions -pthread -flto")
string(APPEND LEANC_EXTRA_CC_FLAGS " -pthread")
unconditionally in its Emscripten branch, with no option to disable it. We want a
thread-free comparison build (no SharedArrayBuffer requirement, so the artifact can load
without cross-origin isolation). Our only route is -sUSE_PTHREADS=0, i.e. a deprecated
setting that a future emsdk may remove and that EMCC_STRICT already rejects.
What would help
Any one of these would remove the dead end, in rough order of preference:
- A supported negation of
-pthread---no-pthreadis the spelling most people try
first (clang accepts it for the host, which is why it fails silently here). - Keep
-sUSE_PTHREADS=0working, or exempt it fromSTRICT, until a negation exists. - Failing both, a documentation note in
docs/emcc.txtstating that-pthreadcannot be
negated and that-sUSE_PTHREADS=0is the workaround, so the deprecation warning does
not lead people to remove their only working option.
Happy to open a PR for (3) if that would be welcome, and happy to test a patch for (1).
Versions
emsdk / emscripten 6.0.9, Linux 6.18 (Manjaro), node 24.
Disclosure: this report was researched and drafted by Claude Opus 5 (Claude Code) working
at my direction. Every flag result in the table above is from a real local probe on 6.0.9,
not a hypothetical, and the cited source behaviour was checked against the installed
emscripten before filing.
- Ngôn ngữ chính
- C++
- Star
- 27.8k
- Fork
- 3.6k
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 179
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của emscripten-core/emscripten
-
`other.test_cmake_cxx_import_std` fails on CMake 3.30–4.0.2 due to missing `CMAKE_EXPERIMENTAL_CXX_IMPORT_STD` UUIDsCó thể đã có người làm @subhaushsingh đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
emscripten-core/emscripten#28160 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
emscripten-core/emscripten#27994 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
LEGACY_GL_EMULATION: generated fixed-function fragment shaders use mediump — fp16 overflow where mediump is half precisionCó thể đã có người làm @TheTomBritton đã nhận 12 ngày trước. Đang mởDesktop OpenGL emulation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
emscripten-core/emscripten#27948 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
emscripten-core/emscripten#27906 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
run_python, run_python_compiler could readlink -fCó thể đã có người làm @kapouer đã nhận 128 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
emscripten-core/emscripten#27211 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của emscripten-core/emscripten
Issue tương tự
-
Linux npm packaging leaves workspace files that block subsequent CI checkoutCó thể đã có người làm @Spockkk0225 đã nhận hôm nay. Đang mởci
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
alibaba/neug#1195 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 3 ngày
-
QA/No release-notes/exclude tests tests/missing-coverage tests/test-quality
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 71/100
brave/brave-browser#61019 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
? - Needs Triage bug CUTLASS C++
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 4 ngày