cgen: restore pthread_t fallback for freestanding vinix builds#27067
cgen: restore pthread_t fallback for freestanding vinix builds#27067medvednikov wants to merge 2 commits into
Conversation
When `-os vinix` is used on a libc host (e.g. glibc on Linux for util-vinix CI), V's hardcoded `typedef struct __thread_data *pthread_t;` collided with libc's own pthread_t typedef pulled in transitively via <sys/types.h>. Use __has_include to delegate to <pthread.h> when libc is available, falling back to V's own forward declaration only when no libc is present. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
957dbaf made the vinix prelude conditionally include <pthread.h> so a glibc host doesn't redefine pthread_t when cross-compiling for vinix, but removed the unconditional typedef. On a true freestanding vinix build (no libc, __has_include(<pthread.h>) false) cgen still emits 'typedef pthread_t Tname;' (cgen.v:11087) and 'pthread_t thread_X;' (spawn_and_go.v:182), which then fail to compile with 'unknown type name pthread_t'. Restore the original forward declaration in the #else branch so both libc and freestanding hosts get a definition. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e0a8f9074
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // does not produce conflicting redefinitions of pthread_t. On a true | ||
| // freestanding vinix build (no libc, no <pthread.h>), fall back to V | ||
| // own forward declaration so generated typedef pthread_t ... still parses. | ||
| #if defined(__has_include) && __has_include(<pthread.h>) |
There was a problem hiding this comment.
Using #if defined(__has_include) && __has_include(<pthread.h>) is not portable to preprocessors that do not implement __has_include: those preprocessors still need to parse the full expression and can fail before short-circuiting. GCC’s preprocessor docs explicitly call this combined form non-portable and recommend two nested #if checks. In vinix builds that use a C compiler without __has_include support, this can turn the generated C prelude into a hard compile error.
Useful? React with 👍 / 👎.
1 participant
No description provided.