LNK1210 in Visual Studio 2008

Question

I receive the following error when linking Chromium project:

Linking...
LINK.EXE.SUPALINK_ORIG : ..\build\Debug\chrome.dll not found or not built by the last incremental link; performing full link
   Creating library ..\build\Debug\lib\chrome_dll.lib and object ..\build\Debug\lib\chrome_dll.exp
LINK.EXE.SUPALINK_ORIG : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO

There is a similar question for VS2005. Somehow it is weird since the linker is already doing the full link. When setting /INCREMENTAL:NO it is linked successfully, but incremental linking is disabled.

Is there a way I can increase ILK size limit to enable incremental linking?

Answer 1

According to a Microsoft source, there are some hard size limits to the ILK size, but it does vary to some extent with the VS version and the OS environment:

• VS2005 has an ILK file limit of 256MB
• VS2008 has an ILK file limit of 256MB on a stock Win32 OS, or
  • a 384MB limit if running on a Win32 OS with the /3GB option used, or
  • a 768MB limit if you're running on a Win64 OS

Source: This MS Connect incident record, which also mentions some drawbacks to using the /3GBthat you may want to take into account.

Since you're running on a Win64 OS (per your comment), I think that you're probably getting the largest ILK file size limit. The /3GB option applies only to 32-bit OS installations - when run under WoW64 32-bit 'large address aware' applications get a full 4GB of address space - there's no need for the /3GB option.

But wait - I have an idea (possibly a harebrained idea). I don't know if this will actually work to solve the incremental link problem you're running into, and even if it does, it still might not be worthwhile because it's probably a lot of trouble, especially maintenance-wise:

You might want to see if using the x64 native linker can work around the problem - if you install the x64 compiler option, VS installs several sets of compiler/link tools for various combinations of x86/x64 target and x86/x64 host platform. As far as the compiler goes, to generate x86 code there is only a Win32 compiler, but for generating x64 code there is both a Win64 compiler and a Win32 'cross compiler' toolchain. However, for the linker it appears that either of the linkers (Win32 or Win64 - the 'cross' version of the linker is simply a copy of the Win32 version) can generate an x86 or x64 target.

It wouldn't surprise me too much if the native Win64 linker can handle larger ILK files than the native Win32 linker, so it might be worth a test if your current build process is using the Win32 (or Win32 'cross') tools.

If you're targeting for x64, make sure that your build process is using the native x64 tools in VC\bin\amd64 instead of the cross tools in VC\bin\x86_amd64. If you're using a regular VS IDE C++ project to build, you might have to switch to a makefile project to force the native x64 tools to be used.

If you're targeting for x86, things might be a little trickier - the compile stage of the build needs to use the x86 tools in VC\bin, but then for the link stage you'll need to use the x64 native linker in VC\bin\amd64. Specify the /machine:x86 option and make sure you have the lib search path set to find x86 libraries instead of the x64 libs. This works - at least for a small test program. But I like I said, I don't know if it'll actually help with the increment link problem you're running into, or that it'll be worth the trouble even if it does.