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
Right now for shader crate to compile crate-type = ["dylib"] is needed to be specified in Cargo.toml.
This is annoying in case when a library is not just a shader, but also a regular dependency of other crates since this makes compiler generate extra libshader_crate.so shared objects in target/{release,debug}.
This can be worked around with cargo rustc --crate-type dylib when compiling normally, so maybe codegen backend or cargo-gpu could do something like that transparently and implicitly?
Feel free to move this into cargo-gpu repository if it makes more sense to be there. Has nothing to do with cargo-gpu.
FYI declaring it as crate-type = ["lib", "dylib"] will make the CPU build link in the static lib instead of using the *.so, but will still needlessly build the *.so.
dylib being used so rarely has revealed some issues in the past as well, causing weird failures.
On --crate-type dylib: while the cargo rustc cmd does have a --crate-type, cargo build or run or test do not. And we primarily rely on cargo build to build and link everything. So we'd either need cargo to add support for that, or figure out some other way to extract all the rlibs we need to link from cargo.
Changing link-time capabilities does not require a clean recompile, unlike the current spirv capabilities.
This would also need some kind of custom linking, though the information retrieval from cargo on what needs to get linked would likely be separate from however any variations of linking we do internally.
FYI declaring it as crate-type = ["lib", "dylib"] will make the CPU build link in the static lib instead of using the *.so, but will still needlessly build the *.so.
I know, that is exactly what I do right now.
On --crate-type dylib: while the cargo rustc cmd does have a --crate-type, cargo build or run or test do not. And we primarily rely on cargo build to build and link everything. So we'd either need cargo to add support for that, or figure out some other way to extract all the rlibs we need to link from cargo.
This is exactly why I thought about cargo-gpu: even if it is not possible to remove the requirement directly, cargo-gpu could still call cargo rustc internally and use that option.
I thought this is gonna be hard. But after researching the differences between cargo build and cargo rustc, I noticed that they're pretty much the same. cargo rustc just allows you to pass some additional args to rustc, like --crate-type=dylib. So this is actually trivially easy: #477
Activity
Firestar99 commentedon Dec 4, 2025
FYI declaring it as
crate-type = ["lib", "dylib"]will make the CPU build link in the staticlibinstead of using the*.so, but will still needlessly build the*.so.Firestar99 commentedon Dec 4, 2025
I would love to remove that requirement!
dylibbeing used so rarely has revealed some issues in the past as well, causing weird failures.On
--crate-type dylib: while thecargo rustccmd does have a--crate-type,cargo buildorrunortestdo not. And we primarily rely oncargo buildto build and link everything. So we'd either needcargoto add support for that, or figure out some other way to extract all therlibs we need to link from cargo.Related: In RFC: link-time capabilities, I've suggested this:
This would also need some kind of custom linking, though the information retrieval from cargo on what needs to get linked would likely be separate from however any variations of linking we do internally.
nazar-pc commentedon Dec 4, 2025
I know, that is exactly what I do right now.
This is exactly why I thought about
cargo-gpu: even if it is not possible to remove the requirement directly,cargo-gpucould still callcargo rustcinternally and use that option.Firestar99 commentedon Dec 4, 2025
I thought this is gonna be hard. But after researching the differences between
cargo buildandcargo rustc, I noticed that they're pretty much the same.cargo rustcjust allows you to pass some additional args torustc, like--crate-type=dylib. So this is actually trivially easy: #477