#Missing DLLs when using dynamic linking on Windows.

31 messages · Page 1 of 1 (latest)

fluid agate
#

I have a bevy application that I have set up to use dynamic linking, only when I try to run the program it is looking for a bevy_dylib-*some_hash_value*.dll instead of the bevy_dylib.dll that is built along side the executable. On top of that it is asking for a std-*some_hash_value.dll which I don't have any version along side the built program. I followed the guide here: https://bevyengine.org/learn/book/getting-started/setup/ to setup dynamic linking and the trouble shooting page doesn't mention anything about missing similar named DLLs. Any help would be appreciated

Bevy Book: Setup

Bevy is a refreshingly simple data-driven game engine built in Rust. It is free and open-source forever!

barren bough
#

You need to run your program using cargo run

#

When you release a game you need to remove the dynamic linking feature and do cargo build --release, then you should be able to open the exe directly

fluid agate
#

Thanks, cargo run works. But trying to debug in RustRover doesn't work unfortunately. Also running via cargo run has this error every frame Resource state (0x4: D3D12_RESOURCE_STATE_RENDER_TARGET) of resource (0x000001FF3B8CD5C0:'Unnamed ID3D12Resource Object') (subresource: 0) is invalid for use as a INITIAL|PRESENT

#

This is also just for the standard bevy app with default plugins. I haven't messed with any setting in bevy yet

barren bough
#

Hmm debug in RustRover has been working for me with the default settings, not sure how to fix that 😦
The error every frame is a known issue, the workaround is to explicitly set a WGPU backend (for example add WGPU_BACKEND=vulkan to your environment variables in RustRover)

fluid agate
#

Hmm, that's interesting I am just running the default run --package colony_sim --bin colony_sim that RustRover made for me when I created the new project.

#

Changing that to just be run results in the same behaviour

barren bough
#

Huh, I've never seen it add those flags

fluid agate
#

Normally I make my rust projects via the command line which means I have to add a run commmand manually. But this time I let RustRover set it up and that's the default settings

barren bough
#

Ah yeah now that you mention it I've never even setup a project through RR

thick trail
#

What error are you getting trying to debug it? Is the CWD in your run configuration set to your project root?

fluid agate
#

Same errors as above about the missing DLLs. Running via RustRover is fine, but as soon as I debug it gives those errors. The CWD is the project root, aye.

fluid agate
#

I just replicated the same project from scratch using the command line instead of using RR and then tried to debug in RR again with the same result

#

Or mostly the same result. I didn't need to manually set the backend variable to Vulkan this time. It just defaulted to Vulkan

thick trail
#

IIRC the fun part of that bug is the driver choosing to use vulkan in some parts and DX in other parts, which is why choosing one or the other fixes it

#

I don't use RR, but I am finding the same DLL errors in CLion with my own (non-generated) project, so long as I try to debug it with dynamic_linking enabled

fluid agate
#

Oh fun, non-determinate behaviour. My favourite /s 🤣

#

I have found a potential workaround online. But I hazard to call it a solution because it involves adding the directories in your target folder that correspond to the missing DLLs to your systems path

#

Which seems like a great way to bloat your path to all holy hell depending on how many bevy projects you have going at once

thick trail
fluid agate
#

Nah, this was a ticket in the Bevy github. Looks like there is a similar issue when trying to debug in VSCode as well

#

Actually, that is the same solution. Just a different ticket yeah

restive hornet
thick trail
#

Ah, I was under the impression that IntelliJ was problematically messing with the paths, but that makes sense it's a more general cargo problem

restive hornet
#

it's actually a cargo issue ya

#

the thing is that 99.99% of rust projects don't dynamically link so most users never have the problem.

fluid agate
#

That's a shame, while I get that Rust is a primarily source shared language I do wish support for dynamic linking was better. That cargo ticket has been open for a hot minute now