镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

musl targets still fail to compile in 0.1.9: BSD u_int*_t typedefs (same root cause as closed #156) #314

Open

Description

@ohdearquant

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.

Activity

  1. realgetOff commented on Aug 4, 2026

    @realgetOff

    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.

  2. ohdearquant commented on Aug 4, 2026

    @ohdearquant
    Author

    @realgetOff thanks for replying, if already fixed, great, feel free to close this whenever.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions