bevy
bevy copied to clipboard
bevyengine
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.
same here... its an issue with the MSVC-based toolchain maybe not using the the msvc-toolchain could solve it... but not sure what to use on windowes then
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:
[target.x86_64-pc-windows-msvc] rustflags = ["-Zshare-generics=off"]
It mentions a path called /.cargo/.config but I'm not seeing a .cargo folder anywhere. (I do have hidden files shown for reference.) In other places I found this same suggestion they mention cargo.toml but when I try adding that there I get this warning which suggests this isn't actually where it belongs:
warning: unused manifest key: target.x86_64-pc-windows-msvc.linker warning: unused manifest key: target.x86_64-pc-windows-msvc.rustflags
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 cargo.toml as suggested in some of the issues.
.
├── .cargo
│ └── config.toml
├── .gitignore
├── Cargo.lock
├── Cargo.toml
└── src
└── main.rs
You can try this again, this is a normal bevy project, and you need create a folder called .cargo with the config.toml.
And then use cargo clean and cargo run to build your project.
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:
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
rustflags = ["-Zshare-generics=off"]
. ├── .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
.cargowith theconfig.toml. And then usecargo cleanandcargo runto build your project.
Is it supposed to be just cargo run or cargo run --features bevy/dynamic like it says on book/getting-started/setup? Trying the latter did have a change this time around. I got this error instead:
= note: rust-lld: error: undefined symbol: __CxxFrameHandler4 >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$??$_Emplace_reallocate@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@QEAAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@QEAV21@$$QEAV21@@Z) >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$??$_Emplace_reallocate@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@QEAAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@QEAV21@AEBV21@@Z) >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$?newIncludeResult@DirStackFileIncluder@@MEBAPEAUIncludeResult@Includer@TShader@glslang@@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEAV?$basic_ifstream@DU?$char_traits@D@std@@@7@H@Z) >>> referenced 453 more times
rust-lld: error: undefined symbol: __GSHandlerCheck_EH4 >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$?readLocalPath@DirStackFileIncluder@@MEAAPEAUIncludeResult@Includer@TShader@glslang@@PEBD0H@Z) >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$?getDirectory@DirStackFileIncluder@@MEBA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V23@@Z) >>> referenced by glslang.glsltospirv.lib(glslang_c_interface.obj):($unwind$?uflow@?$basic_filebuf@DU?$char_traits@D@std@@@std@@MEAAHXZ) >>> referenced 297 more timeserror: aborting due to previous error error: could not compile
bevy_dylib
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.
https://github.com/rgripper/game-temp-1
You can see my game temp...
It's .cargo, not .cargo..
this repository hasn't modified .cargo/config.toml, you can use that before I say to modify it.
About features, I always set it in Cargo.toml, example:
bevy = { version = "0.4", features = [ "dynamic"] }
Or you clould use cargo run --features bevy/dynamic to run it.
This is written by my mobile phone, cloud have any errors, but you can imitate this.
https://github.com/rgripper/game-temp-1 You can see my game temp... It's
.cargo, not.cargo.. this repository hasn't modified.cargo/config.toml, you can use that before I say to modify it.
If you just go with .cargo in Windows (apparently through Explorer but not through Command Prompt from what I've gathered), this is what happens. If you name it .cargo. though, for some reason Windows considers it a valid filename and it removes the second dot from the path. A few references on this: Link 1, Link 2
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.
About features, I always set it in
Cargo.toml, example:bevy = { version = "0.4", features = [ "dynamic"] }Or you clould use
cargo run --features bevy/dynamicto run it. This is written by my mobile phone, cloud have any errors, but you can imitate this.
That seems like it'd be easier, at least if I can solve this issue I'm having with using bevy/dynamic in the first place.
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 .cargo
Or, you can just git clone my repository and see if it runs on your computer...
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:
If you name it .cargo. though, for some reason Windows considers it a valid filename and it removes the second dot from the path.
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.
To address the original problem the issue was opened for, changing rustflags = ["-Zshare-generics=y"] to rustflags = ["-Zshare-generics=off"] as @Cupnfish suggest in issue #1126 (which I'd thought I'd tried since creating .cargo/config.toml) looks to fix the original error.
The documentation for setting Bevy up could definitely do with explicitly saying where to put things like the rustflags line as well as probably addressing how to create a folder that starts with a dot in Windows in order to be more clear for people who haven't really used Rust or this kind of setup before.
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 :smile:
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 -Zshare-generics is set to off or y.
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:
If you name it .cargo. though, for some reason Windows considers it a valid filename and it removes the second dot from the path.
As the second half of this sentence states, naming a folder
.cargo.through Windows explorer creates a folder named just.cargowithout issue. I'm honestly not sure what about that isn't coming across in what I'm saying.
I’m sorry, for here, My English level is not very high, so before you mentioned some place I misunderstood, I am sorry.
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
-Zshare-genericsis set tooffory.
Have you tried cargo clean before recompiling?
I’m sorry, for here, My English level is not very high, so before you mentioned some place I misunderstood, I am sorry.
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.
Have you tried
cargo cleanbefore recompiling?
Yep. I also tried it with all four combinations of -Zshare-generics on/off, with and without dynamic with a cargo clean before every single one of them. It seems like the one time it ran fine might've just been some strange fluke or something.
I’m sorry, for here, My English level is not very high, so before you mentioned some place I misunderstood, I am sorry.
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.
Have you tried
cargo cleanbefore recompiling?Yep. I also tried it with all four combinations of
-Zshare-genericson/off, with and withoutdynamicwith acargo cleanbefore every single one of them. It seems like the one time it ran fine might've just been some strange fluke or something.
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 lld-linker is not compatible with this setting. How long after that, when I reset my project again, the linker was successfully enabled again. But let’s see if turning off lld-linker solves your problem. In my experience, even without lld-linker and with dynamic linking, incremental compilation is still fast.
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
lld-linkeris not compatible with this setting. How long after that, when I reset my project again, the linker was successfully enabled again. But let’s see if turning offlld-linkersolves your problem. In my experience, even withoutlld-linkerand with dynamic linking, incremental compilation is still fast.
Unfortunately this doesn't seem to have worked either. It gives error: linking with link.exe failed: exit code: 1120 followed by an enormous list of filepaths (looks to be mostly references to the temp folder in %appdata% as well as some .lib references) followed by this:
SPIRV.glsltospirv.lib(GlslangToSpv.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
SPIRV.glsltospirv.lib(SpvBuilder.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
SPIRV.glsltospirv.lib(SpvPostProcess.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
SPIRV.glsltospirv.lib(InReadableOrder.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
HLSL.glsltospirv.lib(hlslScanContext.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
HLSL.glsltospirv.lib(hlslGrammar.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
HLSL.glsltospirv.lib(hlslTokenStream.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
SPIRV.glsltospirv.lib(Logger.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Pp.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(parseConst.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(PpTokens.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
HLSL.glsltospirv.lib(hlslParseHelper.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(ParseContextBase.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(limits.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(glslang_tab.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(PpAtom.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(IntermTraverse.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Constant.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(RemoveTree.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(propagateNoContraction.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Initialize.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(PpContext.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(reflection.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(iomapper.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Intermediate.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(intermOut.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(linkValidate.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(ParseHelper.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(SymbolTable.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Scan.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(CodeGen.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Link.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(glslang_c_interface.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(ShaderLang.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(PoolAlloc.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
glslang.glsltospirv.lib(Versions.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler4
SPIRV.glsltospirv.lib(SpvBuilder.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
SPIRV.glsltospirv.lib(SpvPostProcess.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
SPIRV.glsltospirv.lib(InReadableOrder.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
HLSL.glsltospirv.lib(hlslParseHelper.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
HLSL.glsltospirv.lib(hlslScanContext.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
HLSL.glsltospirv.lib(hlslGrammar.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
SPIRV.glsltospirv.lib(GlslangToSpv.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(glslang_tab.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(PpAtom.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Pp.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(PpTokens.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(iomapper.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Constant.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(propagateNoContraction.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(ParseContextBase.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(ParseHelper.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Initialize.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(PpScanner.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(reflection.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Scan.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Intermediate.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(intermOut.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(linkValidate.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(glslang_c_interface.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(ShaderLang.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(Versions.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
glslang.glsltospirv.lib(SymbolTable.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4
z:\1_Misc\Projects\__Rust\Notroidvania\Notroidvania\target\debug\deps\bevy_dylib-0d4b0e9147019be1.dll : fatal error LNK1120: 2 unresolved externals
error: aborting due to previous error
error: could not compile `bevy_dylib`
Seems like bevy_dylib in general just REALLY doesn't like Windows at all.
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.
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 nightly-x86_64-pc-windows-msvc using rustup show that I'm seeing. Edit: I think I found it. I'd overlooked a bit that says rustc 1.48.0 (7eac88abb 2020-11-16) which I think is the information you're looking for) but it's the nightly build as book/getting-started/setup directs you to setup for. The exact version would be whatever the latest version of the nightly build was 5-6 days ago.
Can you try cargo +nightly run? I think your current rust version is stable, and you may already have the nightly rust installed on your computer, but you’re not switching to nigthly to run it.
And you can use rustc -V to see your version of rustc.
For example, my version:
rustc 1.50.0-nightly (c609b2eaf 2020-12-20)
Can you try
cargo +nightly run? I think your current rust version isstable, and you may already have thenightlyrust installed on your computer, but you’re not switching tonigthlyto run it. And you can userustc -Vto see your version ofrustc. For example, my version: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 rustflags = ["-Zshare-generics=off"] actually fails and specifically mentions that it only works on nightly so I'm fairly confident that I'd been properly been set to nightly before.) Actual version is rustc 1.50.0-nightly (c609b2eaf 2020-12-20) here as well.
#832 (comment) I followed this method to try to compile, and solved my problem. My
config.tomlNow Looks Like This:[target.x86_64-pc-windows-msvc] linker = "rust-lld.exe" rustflags = ["-Zshare-generics=off"]
FWIW, I was also running into this issue, and the above solved it for me, running with
cargo run --features bevy/dynamic
...
$ rustc -V
rustc 1.51.0-nightly (04caa632d 2021-01-30)
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:
thread 'main' panicked at 'Initializing the event loop outside of the main thread is a significant cross-platform compatibility hazard. If you really, absolutely need to create an EventLoop on a different thread, please use the `EventLoopExtWindows::new_any_thread` function.', C:\Users\forbjok\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.24.0\src\platform_impl\windows\event_loop.rs:136:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\rust-game-engine.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
I am getting this error even on stable rust, which doesn't have the -Zshare-generics option. Hence, the advice given before for fixing the issue, does not actually fix the issue.
This is without even any plugins. I simply cloned the latest bevy main dbd856de and did:
cargo build --example load_gltf --features dynamic
It fails to link with the error:
= note: rust-lld: error: too many exported symbols (max 65535)
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 dynamic feature to be usable on Windows...
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.
would likely end up in a too large dylib too
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:
- one dylib with all non-bevy dependencies (all the rust ecosystem crates that bevy uses)
- one dylib with all of bevy
🤮 🤮 🤮
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 dynamic feature. I know I have been able to add, say, winit or wgpu as direct dependencies on my bevy game without getting errors…
AIUI it should be no problem, as Rust should link it with the one in the dylib, correct?
Indeed
One (very ugly) idea that comes to mind:
- one dylib with all non-bevy dependencies (all the rust ecosystem crates that bevy uses)
- one dylib with all of bevy
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.