LNK1189 "library limit of 65535 obj exceeded" building rustc #53014
Comments
|
Same behavior here for Windows 10, MSVC 2017, x86_64-pc-windows-msvc, 11a9024, only happens in debug mode ( Also reported in #53099 (comment) ? |
|
That does look like the error that I'm having in 53099, yes. I was quite hopeful when I saw your workaround, but setting |
retep998
added
A-linkage
|
Looks like the fact that incremental splits things up into a few thousand codegen units is really biting us hard here. Clearly we need to set some limits on how many objects are being produced, or maybe reconsider how to handle incremental compilation entirely. |
|
This failure happens for me even when I'm not using incremental compilation ( |
|
This doesn't obey |
|
This is breaking production codebases at this point. Can fixing this be prioritised? |
jonas-schievink
added
I-nominated
T-compiler
pnkfelix
changed the title
pnkfelix
changed the title
can you share your config.toml that you are using? Put it into a gist or a detail blocks in a comment here? |
|
triage: P-high. Leaving I-nominated because this seems like a potentially deep issue that we need to address. |
|
It should actually be rather easy to add an upper limit to the number of object files that the compiler creates, if that is the only problem here. |
|
self-assigning to implement a simple upper-bound on number of object files compiler creates, under assumption that the blow-up in common case is due to |
|
(@Zoxc pointed out on Zulip that "objects" here may refer to symbols, not object files. This is plausible, since we were all wondering how we were getting up to 65535 object files before. But it also does not have the same immediately obvious "fix" that we were hoping for.) |
|
The MSDN page says "The limit of 65535 objects or members in a library has been exceeded." The error was also hit here: https://gitlab.kitware.com/cmake/cmake/issues/17841, which mentions: "it hits the msvc limitation (LNK1189) of 65535 symbols per dll", so it seems like the symbol count is indeed the limiting factor. It also seems like this can only be hit if a library (DLL only?) is built that exports 65535 symbols and according to this, "The 64K export limit is due to 16-bit ordinal field in PE". |
|
If it's the number of exported symbols, then there's two fixes:
|
It broke Windows builds: |
I don't understand. Are you referring to something different than applying the |
|
@Zoxc we were able to reproduce it locally by building something with the I can provide a repo with a reproduction case later today if that would be helpful. |
|
I encountered this bug in a 32-bit Windows 7 VM, |
|
(status: I am still under the process of trying to get a basic Windows bootstrap environment set up.) |
|
Okay at this point I have a Windows environment set up, and have successfully built Rust (atop MS Visual Studio 2019 Community Edition). I have not, however, been able to reproduce this bug in that context. @bbqsrc can you provide your repo with a reproduction case? |
|
I am taking a break for a few months and I wont be able to look at this; unassigning self. |
|
triage: this bug has seen zero activity since april, apart from my own notes in failed attempts to reproduce it. So, I'm going to close it for now. If someone else believes they are encountering it and find this thread, please do reopen the ticket, and include all relevant info (including what version of Windows and Visual Studio you are using, and whether it is 32- or 64-bit platform). |
|
@pnkfelix I just reproduced it on my personal windows pc and I am asking myself why can't we just pass /bigobj to linker and forget about it? |
|
@Lesiuk What was the error message and did you change |
|
|
|
@retep998 except that the Did a bit of digging, there's changes that were made to allow support for large ordinals to the binary format: https://github.com/MicrosoftDocs/cpp-docs/issues/873 The official documentation still hasn't been updated (and I did ask why and got stonewalled). However, the feature request initial post has a lot of research into the behaviour. It seems that the linker interprets a UUID generated by typedef struct ANON_OBJECT_HEADER_BIGOBJ {
/* same as ANON_OBJECT_HEADER_V2 */
WORD Sig1; // Must be IMAGE_FILE_MACHINE_UNKNOWN
WORD Sig2; // Must be 0xffff
WORD Version; // >= 2 (implies the Flags field is present)
WORD Machine; // Actual machine - IMAGE_FILE_MACHINE_xxx
DWORD TimeDateStamp;
CLSID ClassID; // {D1BAA1C7-BAEE-4ba9-AF20-FAF66AA4DCB8}
DWORD SizeOfData; // Size of data that follows the header
DWORD Flags; // 0x1 -> contains metadata
DWORD MetaDataSize; // Size of CLR metadata
DWORD MetaDataOffset; // Offset of CLR metadata
/* bigobj specifics */
DWORD NumberOfSections; // extended from WORD
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
} ANON_OBJECT_HEADER_BIGOBJ;So, it should be possible for us to implement this in our toolchain somewhere. |
@Lesiuk could you please supply the versions you are using for Windows and for Visual Studio, and whether they are 32- or 64-bit? In essence, I want to have enough information here for us to have a chance of reproducing the bug locally. |
|
I am running into this issue now as well, building in release mode works fine, but debug mode produces:
OS: Windows 10 Unfortunately, I don't have code to share which reproduces it, as it is happening in my production codebase. However, it does seem to only be an issue when I am building a particular project as a part of my cargo workspace. Take the project out and it builds fine, move it to the workspace exclusions and the workspace builds fine. Let me know if there is any more information that would be helpful, it looks like the only real option my colleagues and I have for now is to stop using the workspace. |
|
@Visic if you add "-Zshare-generics=off" to your |
|
@bbqsrc Yes, adding -Zshare-generics=off to my .cargo/config does make the linker error go away even in my workspace |
|
Hey folks, as the timeline above shows, this ticket was mentioned by @Cupnfish over in bevyengine/bevy#832 (comment) in late 2020 , and as of writing in early 2023, I figured I'd ask if anything here has changed? I'm just chasing leads here so I can enable fast compiles for Bevy on Windows, which is currently documented as not working:
@bbqsrc , from that feature request, it looks like @SamB commented a follow-up research few months after your posts: Would that further help us to implement this in our toolchain somewhere?
@pnkfelix , I can supply my system version info as well as a reproducible example here: Meta
Examplegit clone https://github.com/bevyengine/bevy
cd bevy
git checkout v0.10.0
cargo run \
--features bevy/dynamic_linking \
--example breakoutStdout LogInitially, I was trying to enable
|
|
Looks like LLVM can generate bigobj-compatible object files: |
|
Hey folks. I'm a Windows developer, and I'm hitting this issue. I'd like to re-open this issue and help diagnose it and fix it. There are two very different things that have 16-bit (65,536) limits in the MSVC toolchain:
When Rust uses a large number of CGUs, it greatly increases the number of OBJs submitted to the linker. I have been trying to build Rust on a Windows machine, and I'm running into this failure. So I can reproduce the problem. Is someone available to work with me on getting this fixed, or some kind of mitigation implemented or documented? |
ChrisDenton
added
the
E-help-wanted
|
I'm a new rust/bevy developer on Win 11. I ran into object limit problem building an introductory bevy project, with only a "hello world main.rs. The problem went away once a removed the "dynamic_linking" feature from my Cargo.toml file, which was intend to contribute to faster build times. |
|
The compiler's However, a complication here is that the total number of object files being linked depends on the entire crate graph, so a single compiler invocation cannot easily know if its already close to the limit. For building the compiler itself, it should be simple to make the build system default to a lower number of CGUs on Windows. Currently the number of CGUs seems to default to the number of CPU cores available. Regarding a more general solution: in theory, Cargo should have enough information upfront, to configure the number of CGUs for each crate, right? |
|
I ran into this issue when I tried to link In case anyone fails to reproduce the bug, just use https://github.com/rksm/cargo-add-dynamic for
|
and others
Edit: This happened again after deleting
\build\x86_64-pc-windows-msvc\stage*, so now I'm more concerned than I was before.I pulled master today, ran
x.py test --stage 1 --incremental src\test\codegen, and got the following:(click to expand log of x.py failure)
Maybe some bad interaction with the updated bootstrap compiler?
The text was updated successfully, but these errors were encountered: