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
[Feature Request] Dynamically Linked Shared Objects via Rust Bindings #97
By default when adding the Cargo.toml dependency in rust it will call for cmake.
Would love an option to provide the binaries from the releases tab or make it so it auto downloads the binaries from there too.
Just like typescript at the moment it seems?
@cjpais
So ok I understand that in rust it needs to compile so cmake is mandatory, with that (on windows) you get a transcribe.dll (and only cpu support)
however you are missing vulkan and cuda for example
If I were to enable support for vulkan/cuda
I guess you have two options:
Follow the guide on how to build with rust+cuda/rust+vulkan on the documentation
Use the already built binaries for vulkan/cuda from the Release tab (this is what I am wondering how to do)
I think the main thing is to read the README for the bindings, and if you want to enable the features for Vulkan or CUDA that is laid out in the README
I think, like, how you framed this whole thing just maybe was a bit odd for me to read because I want to know the context of why you're looking for the dynamic linking, and you didn't explicitly say, like, hey, I have a feature request to use the Rust bindings and dynamically link. And give me the rationale for why you're trying to do that as opposed to the static build. I understand that there's real reasons. I'm just trying to understand the context of the problem because I only have a limited amount of time and I don't want to just give my time to one consumer of something. If there's a reasonable way around it for the time being, and I'm basically looking for feature requests that are going to broadly help the community. And, you know, at the end of the day, I actually think that this is a very reasonable request. But I do need more context before I keep issues open on the repo and basically need to sync my time into them. Like every issue is effectively overhead on me
With the llama.cpp builds you can download the cudart and the cuda builds
I don't install the cuda bindings system wide in my machine, I use the ones from the releases tab. Why? Because I see that many projects use different cuda versions, transcribe.cpp provides a dll for cuda 12.X but when you try to install the latest version is 13.3, many different versions of cuda are pinned differently with many other projects (for example in pytorch it is still 13.2), so I just started to download the prebuilt binaries and link them (to ease the different version problem).
To answer the question why one would need to dynamically link, it is to avoid installing the requirements and just drop in a dll and start using a faster backend!
My use case, is a tauri app that is an ASR app, I want to allow to switch between backends and models.
I hope this a bit more clear, and sorry for the back and forth.
Okay, I just want to say I appreciate this discussion. I'm just going to rename the issue and re-open it. It really helps to understand the broader context of what you're trying to achieve and why. So, thank you for taking the time to write it because it really makes it easier for me to try and support. At the end of the day, this is a one-man show, and llama.cpp has many, many, many more contributors than this library right now. I legitimately can't do everything, and also if you want a feature, you can definitely submit a PR for it. And that is generally preferable to issues
I implemented the "use a prebuilt library instead of building from source" half
of this for the Rust sys crate: PR #117.
Design: an OPENSSL_DIR-style env var. Set TRANSCRIBE_DIR to an install
prefix produced by cmake --install of a TRANSCRIBE_INSTALL=ON build and build.rs skips the vendored cmake build entirely, reconstructing the link
line from that prefix's lib*/transcribe-link.json through the same manifest
code the source build already uses — so static and shared prefixes both work
and no new link logic was added. Unset, nothing changes.
Usage:
TRANSCRIBE_DIR=/opt/transcribe cargo build
Cargo features (shared, vulkan, ...) are naturally inert on this path: the
prebuilt already decided its configuration and the manifest records it.
Activity
cjpais commentedon Jul 21, 2026
As far as I'm aware, Rust wants to statically compile and statically link things, so there's going to be no pre-compiles for the moment
FerLuisxd commentedon Jul 22, 2026
What about for linking prebuilts for vulkan and cuda? @cjpais since they are not compiled by default is there a way to link them?
cjpais commentedon Jul 22, 2026
@FerLuisxd can you provide more context for what you are trying to do?
If you want to see an end to end integration of transcribe.cpp distributed take a look at cjpais/Handy
We ship Vulkan as part of the project
FerLuisxd commentedon Jul 23, 2026
@cjpais
So ok I understand that in rust it needs to compile so cmake is mandatory, with that (on windows) you get a transcribe.dll (and only cpu support)
however you are missing vulkan and cuda for example
If I were to enable support for vulkan/cuda
I guess you have two options:
I hope it is more clear now
cjpais commentedon Jul 23, 2026
I think the main thing is to read the README for the bindings, and if you want to enable the features for Vulkan or CUDA that is laid out in the README
I think, like, how you framed this whole thing just maybe was a bit odd for me to read because I want to know the context of why you're looking for the dynamic linking, and you didn't explicitly say, like, hey, I have a feature request to use the Rust bindings and dynamically link. And give me the rationale for why you're trying to do that as opposed to the static build. I understand that there's real reasons. I'm just trying to understand the context of the problem because I only have a limited amount of time and I don't want to just give my time to one consumer of something. If there's a reasonable way around it for the time being, and I'm basically looking for feature requests that are going to broadly help the community. And, you know, at the end of the day, I actually think that this is a very reasonable request. But I do need more context before I keep issues open on the repo and basically need to sync my time into them. Like every issue is effectively overhead on me
FerLuisxd commentedon Jul 24, 2026
With the llama.cpp builds you can download the cudart and the cuda builds
I don't install the cuda bindings system wide in my machine, I use the ones from the releases tab. Why? Because I see that many projects use different cuda versions, transcribe.cpp provides a dll for cuda 12.X but when you try to install the latest version is 13.3, many different versions of cuda are pinned differently with many other projects (for example in pytorch it is still 13.2), so I just started to download the prebuilt binaries and link them (to ease the different version problem).
To answer the question why one would need to dynamically link, it is to avoid installing the requirements and just drop in a dll and start using a faster backend!
My use case, is a tauri app that is an ASR app, I want to allow to switch between backends and models.
I hope this a bit more clear, and sorry for the back and forth.
[-]Rust precompiled binaries[/-][+][Feature Request] Dynamically Linked Shared Object via Rust Bindings[/+][-][Feature Request] Dynamically Linked Shared Object via Rust Bindings[/-][+][Feature Request] Dynamically Linked Shared Objects via Rust Bindings[/+]cjpais commentedon Jul 25, 2026
Okay, I just want to say I appreciate this discussion. I'm just going to rename the issue and re-open it. It really helps to understand the broader context of what you're trying to achieve and why. So, thank you for taking the time to write it because it really makes it easier for me to try and support. At the end of the day, this is a one-man show, and llama.cpp has many, many, many more contributors than this library right now. I legitimately can't do everything, and also if you want a feature, you can definitely submit a PR for it. And that is generally preferable to issues
shaba commentedon Jul 28, 2026
I implemented the "use a prebuilt library instead of building from source" half
of this for the Rust sys crate: PR #117.
Design: an OPENSSL_DIR-style env var. Set
TRANSCRIBE_DIRto an installprefix produced by
cmake --installof aTRANSCRIBE_INSTALL=ONbuild andbuild.rsskips the vendored cmake build entirely, reconstructing the linkline from that prefix's
lib*/transcribe-link.jsonthrough the same manifestcode the source build already uses — so static and shared prefixes both work
and no new link logic was added. Unset, nothing changes.
Usage:
Cargo features (
shared,vulkan, ...) are naturally inert on this path: theprebuilt already decided its configuration and the manifest records it.
cjpais commentedon Jul 28, 2026
Thank you!