Commit c90ff46
builtin: fix GetFinalPathNameByHandleW declaration for TCC on Windows
TCC''s bundled windows.h does not include fileapi.h, so
GetFinalPathNameByHandleW had no C declaration in scope when TCC
compiled any program that pulled in builtin. TCC (in C99 mode) treats
implicit function declarations as hard errors.
Use a compiler-conditional declaration:
- Under TCC, mark it @[c_extern] so V emits a forward declaration
(guarded by #ifndef). TCC''s fileapi.h cannot be included directly
because it pulls in apiset.h, which TCC does not bundle, so supplying
the declaration from V is the only viable route.
- Under GCC/MSVC, declare it bare (no @[c_extern]) so V emits no
declaration and the call resolves against the SDK header that
windows.h pulls in transitively. Emitting a V extern here would
conflict with the SDK''s `DWORD WINAPI` signature (DWORD is
unsigned long, not u32) and fail with -Werror.
The whole block is guarded by $if windows {} so the symbol is not
compiled into Linux/macOS builds, where it does not exist.
Verified: generated C contains the extern only for the TCC backend and
omits it for GCC; `vlib/os/` tests pass (24/24) on Windows with GCC.
Co-Authored-By: WOZCODE <contact@withwoz.com>1 parent 6c4d26f commit c90ff46
1 file changed
Lines changed: 12 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
295 | 295 | | |
296 | 296 | | |
297 | 297 | | |
298 | | - | |
| 298 | + | |
| 299 | + | |
| 300 | + | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
299 | 310 | | |
300 | 311 | | |
301 | 312 | | |
| |||
0 commit comments