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

Most upvoted comments

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.