Skip to content

Try to work around pthread related static linking problem (#1761)#1763

Closed
skef wants to merge 1 commit intodevelopfrom
pthreadfix2
Closed

Try to work around pthread related static linking problem (#1761)#1763
skef wants to merge 1 commit intodevelopfrom
pthreadfix2

Conversation

@skef
Copy link
Copy Markdown
Collaborator

@skef skef commented Nov 15, 2024

No description provided.

skef added a commit that referenced this pull request Feb 11, 2026
**Problem:**
AFDKO 4.0.2 manylinux wheels crash on Linux with:
"terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1"

**Root Cause:**
When statically linking ANTLR4 runtime (as in manylinux wheels), ANTLR4
attempts to use pthread interfaces but the pthread library isn't linked.
This causes std::system_error at runtime when ANTLR4 tries to access
threading primitives.

**Solution:**
Add explicit pthread linking to targets that use ANTLR4:
1. find_package(Threads) in top-level CMakeLists.txt
2. Link Threads::Threads to _internal (Python module)
3. Link Threads::Threads to afdko (binary)

Both targets transitively include ANTLR4 through hotconv → addfeatures.

**Why it's safe:**
- None of AFDKO's C sources are actually multithreaded
- The pthread linking is only needed to satisfy ANTLR4's runtime checks
- CMake only adds -pthread on platforms where pthreads are available
- Regular dynamic builds already had pthread available implicitly

**Based on:**
PR #1763 by skef, adapted for addfeatures branch structure.
Fixes issue #1761 (manylinux wheel crashes on Linux).

**Verified locally:**
- macOS build still succeeds with this change
- pthread linking is conditional on CMAKE_USE_PTHREADS_INIT

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@skef
Copy link
Copy Markdown
Collaborator Author

skef commented Feb 11, 2026

I'm dealing with this as part of a bulk edit.

@skef skef closed this Feb 11, 2026
skef added a commit that referenced this pull request Feb 11, 2026
**Problem:**
Windows builds fail with:
"error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'"

**Root Cause:**
ANTLR4 was being built with static CRT (/MT) while the rest of afdko
uses dynamic CRT (/MD). Windows doesn't allow mixing static and dynamic
C++ runtime in the same binary.

**Solution:**
Set ANTLR4_WITH_STATIC_CRT=OFF in third_party/antlr4cpp/CMakeLists.txt
before FetchContent_MakeAvailable(). This was already set in the
top-level CMakeLists.txt but needs to be set again locally to propagate
into the FetchContent build.

**Why it matters:**
Python extensions on Windows must use dynamic CRT to match Python's
runtime. Static CRT causes linker errors and potential runtime crashes.

**Pattern:**
Same approach as CMAKE_POSITION_INDEPENDENT_CODE and CMAKE_CXX_STANDARD
which are also set locally to ensure propagation into FetchContent.

**Verified locally:**
- macOS build still succeeds (CRT setting is Windows-only)
- Setting matches top-level CMakeLists.txt:39

Fixes Windows wheel builds. Related to PR #1763 / issue #1761.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant