LINK : fatal error LNK1189: library limit of 65535 objects exceeded #1110
Comments
|
same here... |
|
Looks like a duplicate of #832 |
I'm not certain if it is since the stuff in the first post of that issue doesn't happen to me but regardless, the solutions in that issue don't seem to actually fix the problem for me unfortunately. It doesn't help that it's not clear on where this part belongs:
It mentions a path called
After looking through Rust and Cargo docs and various issues and posts on forums, I can't figure out where this stuff belongs if not in |
memoryruins
added
A-Build-System
.
├── .cargo
│ └── config.toml
├── .gitignore
├── Cargo.lock
├── Cargo.toml
└── src
└── main.rsYou can try this again, this is a normal bevy project, and you need create a folder called |
|
#832 (comment) [target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
rustflags = ["-Zshare-generics=off"] |
Is it supposed to be just
I also ran into one other unforeseen issue. Apparently Windows doesn't allow you to simply name a folder |
|
https://github.com/rgripper/game-temp-1 |
|
About features, I always set it in bevy = { version = "0.4", features = [ "dynamic"] }Or you clould use |
If you just go with Edit: Finally found something directly addressing why it happens here. It happens because Windows considers it a file with an extension but no name. The second dot seems to be a workaround added in Windows 7 from what I've gathered.
That seems like it'd be easier, at least if I can solve this issue I'm having with using |
|
I’m not using Windows 7, But I found out that Windows 7 doesn’t allow you to create folders that start with a dot, but you can do that with Cmd: mkdir .cargoOr, you can just git clone my repository and see if it runs on your computer... |
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 |
|
To address the original problem the issue was opened for, changing The documentation for setting Bevy up could definitely do with explicitly saying where to put things like the |
|
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 😄 |
|
It seems I might have spoken too soon. After getting it to work once, I'm now back to getting the same error I had in this post. And this time I'm getting it whether |
I’m sorry, for here, My English level is not very high, so before you mentioned some place I misunderstood, I am sorry. |
Have you tried |
No worries. Sorry if I sounded a bit harsh myself. My frustration with the situation might've made me come across as a bit more cross than I'd intended.
Yep. I also tried it with all four combinations of |
Can you try this? [target.x86_64-pc-windows-msvc]
rustflags = ["-Zshare-generics=off"]I remembered that I had this situation before. It seems that |
Unfortunately this doesn't seem to have worked either. It gives Seems like bevy_dylib in general just REALLY doesn't like Windows at all. |
What’s Your Rust version? Yesterday, I was talking to a friend about it, and he told me it might have something to do with Rust’s version, I’ve been using the Rust’s nightly version, you can try the latest. |
I'm not sure how to check the exact version (there doesn't seem to be a way to check anything more specific than |
|
Can you try rustc 1.50.0-nightly (c609b2eaf 2020-12-20) |
Er, oops. That was an error on my end. I'd tried switching to stable yesterday to see if that would do anything differently and forgot to change back afterwards. (According to when I did try it yesterday, any attempt at using |
FWIW, I was also running into this issue, and the above solved it for me, running with |
|
I'm getting the same issue when trying to use the dynamic feature both with the VS2019 linking tool and LLD. I tried @Bloodyaugust's fix, but that just results in a different error instead: |
|
I am getting this error even on stable rust, which doesn't have the This is without even any plugins. I simply cloned the latest bevy main It fails to link with the error: OS: Windows 11 The same error happens if I try to cross-compile a Windows executable from Linux. |
|
According to Microsoft, the only "solution" to this issue is to split things into multiple smaller DLLs... :( https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk1189 Looks like we might have to find some way to do that, if Bevy wants the |
|
That is going to be tricky as we can't really prevent a single dependency to end up in multiple dylibs unless we add an extra dylib that links in those dependencies which would be hard to keep in sync and would likely end up in a too large dylib too. Rustc doesn't accept a crate ending up in multiple dylibs. |
I can confirm that bevy built without default features is small enough to fit under the limit. One (very ugly) idea that comes to mind:
🤮 🤮 🤮 I think that is likely to work, though. Each of the dylibs would likely be under the limit. There is a clean separation between "lower level" and "higher level" in the dependency tree (no siblings with common deps, therefore no duplicate crates). One thing to consider is what happens if a user project directly depends on one or more of the same crates that Bevy depends on. AIUI it should be no problem, as Rust should link it with the one in the dylib, correct? I think this is already the situation with the current |
Indeed
That could work. It would be non-trivial to keep the dependencies of the non-bevy dep dylib in sync with the actual dependencies of the various bevy crates. Especially across all possible feature combinations. |
|
currently running bevy with the dynamic feature while targetting msvc windows from within wsl gets me this error when im trying to run my game, it also throws an error for the bevy dylib asking for one with random string, if you rename bevy dylib it doesnt error out for it but i cant get further
|
You have to add the target/x86_64-pc-windows-msvc/release/deps directory and the directory printed by |
|
publish is just the name i gave the outdir, i read the docs, this is just to make wsl more convenient because opengl isnt supported and vulkan-wsl stuff hasnt been down-streamed yet, also cargo run causes the same error as above for me (might need a cargo clean) |
|
It works for me in stable Rust on Windows 10 with at least in in |
|
I've encountered this issue when using the Minimal repro: [package]
name = "bevy_pixel_camera_crash"
version = "0.1.0"
edition = "2021"
[dependencies]
bevy = { version = "0.8.1", default-features = false }
bevy_pixel_camera = "0.2.0"use bevy::prelude::*;
fn main() {
App::new().add_system(|| println!("Hello world")).run();
}If you run this project using Before I got this error, I got a STATUS_STACK_BUFFER error (likely related to #2921). |
|
Is there anything being done about this? No dynamic on windows gets me 30 sec iterative compile times which makes me sad 😢. |
Possible solutionAdding this to the cargo.toml of my project fixes the # Enable a small amount of optimization in debug mode
[profile.dev]
opt-level = 1
# Enable high optimizations for dependencies (incl. Bevy)
[profile.dev.package."*"]
opt-level = 3I am using the Rust llvm linker in my project's [target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"This was taken from here: https://bevyengine.org/learn/book/getting-started/setup/#compile-with-performance-optimizations |
|
@paul-hansen This does seem to work for now, thx a lot! The bevy book should be changed to mention using this combo. |
|
Bevy's website was updated with this information here: bevyengine/bevy-website#628. I guess we can close and if the issue persists, re-open. |
|
Try to compile a hello world project and got the same linker error. Before every compile I run 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 OS and Project Information
[dependencies]
bevy = { version = "0.13", features = ["dynamic_linking"] }
# Enable a small amount of optimization in debug mode
[profile.dev]
opt-level = 1
# Enable high optimizations for dependencies (incl. Bevy)
[profile.dev.package."*"]
opt-level = 3
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
# rustflags = ["-Zshare-generics=off"] |
Solution taken from here: bevyengine/bevy#1110
|
I have the same issue as @kazeitori on Bevy 0.14. From my main Cargo.toml: bevy = { version = "0.14.*", features = ["dynamic_linking", "file_watcher"] }
[profile.dev]
opt-level = 1
[profile.dev.package."*"]
opt-level = 3
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe" |
|
I'm guessing Bevy has gotten bigger and even with optimizations enabled it still exceeds the Windows symbol limit for dynamic libraries. I personally moved to Linux so haven't tried it on Windows for awhile. If that's the case, the only solutions I can think of is looking into making it multiple dynamic libraries (maybe each Bevy crate?) or just documenting that dynamic_linking doesn't work on Windows again. |
|
Having multiple dynamic libraries would really be ideal. Not only to fix the Windows issue, but it would make compilation for Bevy plugins that don't depend on all of Bevy much faster too... in theory. |
|
Yeah even with |
|
Splitting it into multiple DLLs will quickly become messy as rustc allows each crate to be statically linked into at most a single dylib, yet cargo doesn't offer any assistance in ensuring that this is the case for indirect dependencies. It only works well if you have each dylib depend on only a single other dylib as in that case rustc will always choose linking vs not linking for each crate in such a way that no two dylibs end up with the same crate statically linked into it. |
share-generics overruns the limit, but off, i am able to link fine still. |
Bevy version
0.4.0 (3b2c6ce)
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/dynamicstep things seem to have gone awry though.What actually happened
Got a linker error from bevy_dylib with this error code:
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.The text was updated successfully, but these errors were encountered: