Win10: Trying to link Bevy dynamically results in the error `STATUS_ENTRYPOINT_NOT_FOUND`

[TheZalli]

Bevy version

0.4

Operating system & version

Windows 10, version: 1909, OS build: 18363.1256, 64-bit

What you did

I ran the binary with cargo run --features bevy/dynamic as instructed by the Bevy book. I believe I had the correct software and the given config.toml file at the folder .cargo

What you expected to happen

The game running regularly and opening my screen, just like when not using the features flag.

What actually happened

After the cargo started running the application, it exited with the error message:
error: process didn't exit successfully: `target\debug\<crate>.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

Additional information

The current code is basically a very slightly modified version of the 3d scene example from the repo, with only main.rs in the src folder and no other dependencies besides Bevy 0.4.

I tried removing the "-Zshare-generics=y" flag from .cargo/config.toml, and also running it with stable. Both variations had the same result and message.

When I had only the cargo's autogenerated helloworld in my main.rs, the binary functioned normally with and without the flag, which is why I believe that my setup should be correct.

[cart]

Hmm yeah a number of people are reporting issues with dynamic linking on windows. Currently I'm working from my linux/mac laptop, so I won't be able to investigate Windows-related issues until I get back to my desktop in early-January. I'm hoping a motivated Windows user will pick this up before then 😄

[goooosick]

Building without fast-build configuration gives link error 1189 (too many objects). It compiles with fast-build, but the generated DLL has exact 65536 functions exported. It seems the DLL being sliently truncated.

[cart]

I have a feeling that glsl-to-spirv is the culprit. Basically every link issue we've had in the past can be traced back to it. Maybe try removing that dep and commenting out relevant code until it compiles? It wouldn't work but if we don't get the link error, then we have our culprit.

[Cupnfish]

I’ve encountered all of these problems and found a solution, and I think we should create a README file for anyone who has a problem to solve.
STATUS_ENTRYPOINT_NOT_FOUND：
1.Create a cargo profile under your game project, such as this:

├── .cargo  
│   └── config.toml
├── .gitignore
├── Cargo.lock
├── Cargo.toml
└── src
    └── main.rs

2.Modify the config.toml file as:

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
rustflags = ["-Zshare-generics=off"]   # Here is the key to solving this problem

3.(optional) next modify your Cargo.toml makes it easy for you to run your project directly:

[dependencies]
bevy = { version = "0.4", features = ["dynamic"] }

4.Run your project happily:

cargo run

If you did not choose 3：

cargo run --features bevy/dynamic

This method also applies to #1110

I need your feedback.

[goooosick]

@Cupnfish I think you're right. There are over 90k monomorphized functions from rust core in .so file built on linux. Disabling share-generics makes total exported functions down to 19k on windows.

[Keithcat1]

For me, using link.exe instead of rust-lld.exe on Windows fixed the problem.
But I can only compile in release mode or I get that error message: bevy_dylib.dll has more than 65535 objects.

[TheZalli]

@Cupnfish
Doing that seems to have worked for me, thank you.

[alice-i-cecile]

I can verify that @cupnfish's solution is working for me on Windows :)