Library limit of 65535 objects exceeded

Hi, I'm getting started with Bevy and was trying some of its examples. I was using Windows MSVC. I copied the example code of rect.rs, then added [dependencies]bevy = { version = "0.7.0", features = ["dynamic"] } to cargo.toml, then cargo r. However after a long compilation of 260 crates, it finally showed such a error:

error: linking with `link.exe` failed: exit code: 1189
  |
...
 = note: LINK : fatal error LNK1189: library limit of 65535 objects exceeded

If I use cargo r --release, it shows:

thread 'main' panicked at 'Unable to find a GPU! Make sure you have installed required drivers!'

I wonder if the limits to the number of the libraries make the compilation incomplete? Is there any approaches to fix it?

edit: the code of rect.rs

use bevy::prelude::*;
fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_startup_system(setup)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn_bundle(OrthographicCameraBundle::new_2d());
    commands.spawn_bundle(SpriteBundle {
        sprite: Sprite {
            color: Color::rgb(0.25, 0.25, 0.75),
            custom_size: Some(Vec2::new(50.0, 50.0)),
            ..default()
        },
        ..default()
    });
}

Thank you for any thoughts!

I'm not familiar with bevy, but this sounds like you are running up against a limitation in the MSVC linker. You can switch to using the LLVM linker by creating .cargo/config.toml and adding this to it:

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

It sounds like this is not an uncommon problem people run into with bevy:

5 Likes

Thank you! The compilation works, but run fails.
the error from cargo r tells no much:

error: process didn't exit successfully: `target\debug\breakout.exe` (exit code:
 0xc000007b)

If I directly click on the excutable, it would say, bevy_dylib-e09dc446b22a1a38.dll was missing, so I found one in target//debug//deps and copied into target//debug. But it would then say, std-13da5b615652700a.dll was missing, and this time it was no where to be found.
What was truly missing in the whole process? I' ve read the begining part of the bevy book but did not found any information about it.

I've tried:

[target.x86_64-pc-windows-msvc]
rustflags = ["-Zshare-generics=off"]

then,

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

and then,

[target.x86_64-pc-windows-msvc]
linker = "lld-link.exe"
rustflags = ["-Clinker=lld", "-Zshare-generics=y"]

and etc.
However the error still remains.
Sorry, perhaps I had better ask on github. Thanks anyway!

Have you cargo clean-ed between re-runs? Also, the Bevy Discord is a great place to get answers fast :smile:.

1 Like

Cargo extends the dynamic library search path (on windows this is the same as the executable search path, that is PATH) with the target/debug/deps dir and rustup extends it with the dynamic library directory of rustc itself. (the output of rustc --print sysroot extended by /lib on unix or /bin on windows.) This later location is where std.dll can be found. You can also use rustup run stable target/debug/breakout.exe for std.dll.

A quick search seems to indicate that this exit code means that either the executable is corrupt or it is missing a dll.

1 Like

Yes, I did. And I even tried creating a new project.

It was there, however simply coping into target//debug did not solve the problem. My current environment was msvc nigntly, and with this

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

in .cargo//config.
There were lots of ppl encontering this problem, but in my case this seems not so easy to solve. I would try to seek of another engine instead.
Thank you again!

You should probably just disable the dynamic feature of bevy. It seems like it just doesn't work correctly on windows due to windows toolchain limitations.

1 Like

Well, I've already read this on the bevy book, so I did.

Does it work with the dynamic feature disabled and using the defauly linker?

1 Like

I had been trying without it from the start, and the error just showed up. But now I've switch to Windows 10 (previously, Win 7) and all was fine! The config was just as in the file config_fast_builds. Strange, isn't it? I will try to figure out what was wrong with my environment in Windows 7.