You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
musl targets still fail to compile in 0.1.9: BSD u_int*_t typedefs (same root cause as closed #156) #314
Reproduced today with sqlite-vec 0.1.9 as a Rust crate dependency, cross-compiling with cargo-zigbuild to aarch64-unknown-linux-musl:
sqlite-vec.c:68:9: error: unknown type name 'u_int8_t'
68 | typedef u_int8_t uint8_t;
sqlite-vec.c:69:9: error: unknown type name 'u_int16_t'
69 | typedef u_int16_t uint16_t;
sqlite-vec.c:70:9: error: unknown type name 'u_int64_t'
70 | typedef u_int64_t uint64_t;
Same root cause as #156 (closed without a code change): the u_int8_t/u_int16_t/u_int64_t names are BSD/glibc extensions from sys/types.h. musl deliberately does not define them, so every musl target (x86_64 and aarch64 alike, any linker) fails at these three lines while glibc, macOS, and Windows builds pass.
Suggested fix: the standard C99 fixed-width types these typedefs are trying to produce already exist in <stdint.h> on every supported platform — replacing the three typedef u_int*_t ... lines with #include <stdint.h> (or guarding the typedefs to only apply where uint8_t is genuinely absent) makes the file portable to musl with no behavior change elsewhere.
Filing because static-musl builds are a common deployment shape for embedded/edge targets, and the failure is currently a hard blocker for any Rust project bundling sqlite-vec on those targets.
This looks fixed on main already, so it may just need closing.
The three typedef u_int8_t uint8_t; lines at sqlite-vec.c:68-70 were removed in 85cf415 ("Remove dead typedef macros and harmful u_int*_t redefinitions", 2026-03-31), which first shipped in v0.1.10-alpha.2. git merge-base --is-ancestor 85cf415 HEAD confirms it's on main, and grep -rn 'u_int[0-9]*_t' *.c now returns nothing.
Since this issue and #287 (FreeBSD/clang-19) are the same three lines, both are reports against 0.1.9, which predates the fix. Worth a v0.1.10-alpha.2-or-later retest to confirm on a real musl target before closing — I verified the source, not a cross-compile.
Activity
realgetOff commentedon Aug 4, 2026
This looks fixed on
mainalready, so it may just need closing.The three
typedef u_int8_t uint8_t;lines atsqlite-vec.c:68-70were removed in 85cf415 ("Remove dead typedef macros and harmful u_int*_t redefinitions", 2026-03-31), which first shipped inv0.1.10-alpha.2.git merge-base --is-ancestor 85cf415 HEADconfirms it's onmain, andgrep -rn 'u_int[0-9]*_t' *.cnow returns nothing.Since this issue and #287 (FreeBSD/clang-19) are the same three lines, both are reports against
0.1.9, which predates the fix. Worth av0.1.10-alpha.2-or-later retest to confirm on a real musl target before closing — I verified the source, not a cross-compile.ohdearquant commentedon Aug 4, 2026
@realgetOff thanks for replying, if already fixed, great, feel free to close this whenever.