bevy: LINK : fatal error LNK1189: library limit of 65535 objects exceeded

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"]

#832 (comment) 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"]

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)

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.

# 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

I am using the Rust llvm linker in my project’s .cargo/config.toml file as well:

[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 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.

c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: export ordinal too large: 399813
          collect2.exe: error: ld returned 1 exit status

Then I changed the rust toolchain to msvc, but it produces the same problem.

  = note: rust-lld: error: too many exported symbols (got 400174, max 65535)

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 for profile.dev and 2 for profile.dev.packages.* but the same problem. I tried both rust-lld and msvc’s link but got the same problem. I tried to switch to nightly but got compiling errors for some dependencies.

OS and Project Information

PS C:\> (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion")
ProductName               : Windows 10 Pro
ReleaseId                 : 2009
SoftwareType              : System
UBR                       : 4046

PS C:\> rustup show
Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.76.0 (07dca489a 2024-02-04)

PS C:\> rustup --version
rustup 1.26.0 (5af9b9484 2023-04-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.76.0 (07dca489a 2024-02-04)`

%WORKSPACE%/%PACKAGE%/Cargo.toml

[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

%WORKSPACE%/.cargo/config.toml

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
# rustflags = ["-Zshare-generics=off"]

@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

[profile.dev]
opt-level = 0

[profile.dev.package."*"]
opt-level = 2

in Cargo.toml, and

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

in .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 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 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.

.
├── .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.

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 times

error: 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.