bevy: LINK : fatal error LNK1189: library limit of 65535 objects exceeded
Bevy version
0.4.0 (3b2c6ce49b3b9ea8bc5cb68f8d350a80ff928af6)
Operating system & version
Windows 10 64-bit (version 1709)
What you did
I was just following the setup instructions here. When I tried to follow the cargo run --features bevy/dynamic
step things seem to have gone awry though.
What actually happened
Got a linker error from bevy_dylib with this error code:
LINK : fatal error LNK1189: library limit of 65535 objects exceeded
error: aborting due to previous error
error: could not compile `bevy_dylib`
Additional information
This is my first time messing with Rust and I’m not at all familiar with this kind of toolchain so there could very easily be something I’m doing wrong but I was just following the directions on the getting started/setup page so I’m not sure what I would have done wrong here. Looking around I’ve found old issues saying to try rustflags = ["-Zshare-generics=y"]
but I have absolutely no idea where to put this and searching around is frustratingly unhelpful since every mention I can find of it it just someone telling someone to try it. Putting it in my project’s cargo.toml seems to do nothing. I seem to have been able to accomplish the other steps on that page that come after without issue though. I did the LLD linker bit as well as the nightly Rust compiler bit and adding bevy in my cargo.toml dependencies. I also seem to have accomplished the copy+paste of code on the getting-started/apps and up to “Your First System” bit on getting-started/ecs so I’m not sure if this issue is something I have to worry about or not before continuing.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 28
- Comments: 40 (21 by maintainers)
Commits related to this issue
- Adds a couple of flags to Cargo.toml to fix build error on Windows. Solution taken from here: https://github.com/bevyengine/bevy/issues/1110 — committed to erezsh/hexx by erezsh 2 months ago
https://github.com/bevyengine/bevy/issues/832#issuecomment-748554685 I followed this method to try to compile, and solved my problem. My
config.toml
Now Looks Like This:FWIW, I was also running into this issue, and the above solved it for me, running with
Possible solution
Adding this to the cargo.toml of my project fixes the
too many exported symbols (got 199075, max 65535)
error for me even on stable Rust.I am using the Rust llvm linker in my project’s
.cargo/config.toml
file as well:This was taken from here: https://bevyengine.org/learn/book/getting-started/setup/#compile-with-performance-optimizations Can anyone else confirm this fixes it for them? (Note adding this to bevy’s cargo.toml does not make the examples work as it would need to be added to the example’s cargo.toml which isn’t really a thing.)
Try to compile a hello world project and got the same linker error. Before every compile I run
cargo clean
to clean the workspace cache.Then I changed the rust toolchain to msvc, but it produces the same problem.
I follow the Setup and enable the performance optimizations and dynamic linking, but this solution for the previous problem does not work for me. I also tried
opt-level = 0
forprofile.dev
and2
forprofile.dev.packages.*
but the same problem. I tried bothrust-lld
and msvc’slink
but got the same problem. I tried to switch to nightly but got compiling errors for some dependencies.OS and Project Information
%WORKSPACE%/%PACKAGE%/Cargo.toml
%WORKSPACE%/.cargo/config.toml
@paul-hansen This does seem to work for now, thx a lot! The bevy book should be changed to mention using this combo.
It works for me in stable Rust on Windows 10 with at least
in
Cargo.toml
, andin
.cargo/config.toml
.Yeah it definitely sounds like we need to update the docs to inform windows users that they should disable share-generics. In regard to the Windows Explorer folder quirk, I’m not totally convinced we need to tell users how to use their operating system on that level of detail, as each platform will have its own quirks at each step. But its the sort of thing that if enough people get caught on it, id reconsider.
A big thanks to everyone for investigating! Being able to use “dynamic” on Windows is important 😄
I’m not sure you’re understanding what I’m saying. I’ve provided a solution to the folder naming problem on multiple occasions now so cloning your repository is pointless. To quote myself:
As the second half of this sentence states, naming a folder
.cargo.
through Windows explorer creates a folder named just.cargo
without issue. I’m honestly not sure what about that isn’t coming across in what I’m saying.Is it supposed to be just
cargo run
orcargo run --features bevy/dynamic
like it says onbook/getting-started/setup
? Trying the latter did have a change this time around. I got this error instead:I also ran into one other unforeseen issue. Apparently Windows doesn’t allow you to simply name a folder
.cargo.
Instead you need to name it.cargo.
and it will then remove the second dot at the end. This isn’t something I’d ever actually come across myself so it was rather confusing, albeit easy to find info on.