Skip to content

ci(release): ship the C-API shared library and header (#25)#29

Merged
mudler merged 1 commit into
masterfrom
feat/release-capi-shared-lib
Jun 17, 2026
Merged

ci(release): ship the C-API shared library and header (#25)#29
mudler merged 1 commit into
masterfrom
feat/release-capi-shared-lib

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

Closes #25.

The prebuilt release bundles only carried parakeet-cli, so integrating the C-API via ctypes/dlopen meant compiling from source. This adds a separate shared-library bundle per (platform, backend, arch) alongside each existing CLI bundle.

What ships

A new parakeet-<ver>-lib-<platform>-<backend>-<arch> bundle for every existing variant (linux cpu/vulkan/cuda x64 + cpu arm64, macos metal arm64 + cpu x64, windows cpu/vulkan/cuda x64), each containing:

  • libparakeet.so / libparakeet.dylib / parakeet.dll
  • include/parakeet_capi.h
  • LICENSE, README
  • the same cudart/cublas runtime libs on CUDA variants

The lib builds in its own build dir with PARAKEET_SHARED=ON and PARAKEET_BUILD_CLI=OFF, so the CLI bundles stay byte-for-byte unchanged as single self-contained binaries. The release job already globs dist/*, so the new bundles attach with no change there.

Two gotchas the implementation had to handle

  • Linux link failure: BUILD_SHARED_LIBS=OFF builds ggml's static objects without -fPIC, so folding them into a shared lib fails to link (relocation R_X86_64_PC32 ... recompile with -fPIC). The shared-lib configure steps set -DCMAKE_POSITION_INDEPENDENT_CODE=ON.
  • Windows would export nothing: the C-API header uses plain extern "C" with no __declspec(dllexport), so an MSVC DLL exports zero symbols and is useless to ctypes. WINDOWS_EXPORT_ALL_SYMBOLS is set on the parakeet target under the PARAKEET_SHARED branch. No effect on Linux/macOS.

Verification

Built locally on Linux CPU: a self-contained libparakeet.so depending only on standard system libs, with the parakeet_capi_* symbols exported (nm -D). The Windows DLL export and macOS dylib only get exercised on the CI runners; a workflow_dispatch run confirms them without needing a tag.

🤖 Generated with Claude Code

The release bundles only carried parakeet-cli, so integrating via
ctypes/dlopen meant compiling from source. Add a separate shared-library
bundle per (platform, backend, arch) alongside each CLI bundle.

The lib is built in its own build dir with PARAKEET_SHARED=ON and
PARAKEET_BUILD_CLI=OFF, so the CLI bundles stay single self-contained
binaries. Each lib bundle carries libparakeet.{so,dylib,dll}, the
parakeet_capi.h header, LICENSE and README (plus the same cudart/cublas
on CUDA). The release job already globs dist/*, so they attach with no
further change.

Two things that would have silently broken it:

- BUILD_SHARED_LIBS=OFF builds ggml's static objects without -fPIC, so
  folding them into a shared lib fails to link on Linux. The shared-lib
  configure steps set CMAKE_POSITION_INDEPENDENT_CODE=ON.

- The C-API header marks symbols with plain extern "C", no dllexport, so
  an MSVC DLL would export nothing. Set WINDOWS_EXPORT_ALL_SYMBOLS on the
  parakeet target when PARAKEET_SHARED is on. No effect on Linux/macOS.

Verified on Linux CPU: a self-contained libparakeet.so depending only on
standard system libs, with the parakeet_capi_* symbols exported.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@mudler mudler merged commit fa5aeef into master Jun 17, 2026
8 checks passed
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.

Include C-API shared library in release bundles

2 participants