(Setting followup-to to a more limited set of newsgroups.)
From the linker team:
"1. The 64MB limit is there to keep the ILK file from consuming too much of
the memory necessary to perform the link in the first place. It needs to be
reserved up front and doesn't move throughout the link. It holds the
in-memory data for linking which includes other pointers. The fact is,
linking is quite expensive in terms of memory and the larger a project is,
the larger the requirements, in general. We have to balance both the ILK
size and the size remaining we have to work with.
2. I am surprised VC6.0's linker has a different limit. I am certain it has
the same or lower, but that is beside the point now. It may have slipped out
without one and we fixed it. I do know that the intent of 7.0 was to use a
96MB limit, but due to a bug, that limit was not reached.
3. The limit is 256MB on machines running with the /3GB switch. Windows XP
allows /3GB on all SKUs now so that is one option. For the next release we
are raising the limit to 128MB on vanilla NT. It is about at that point that
we start infringing on the memory requirements of the image itself along
with all of the file I/O we have to do to perform the link.
ILK size is roughly equivalent to the image size, so they are a very large
image for x86. The largest image we have been able to link on an x86 machine
is roughly 350MB (an ia64 image). The memory requirements for doing this are
above 1GB of VM. In fact, anything over about 60MB of image size really
benefits from the /3GB switch or running on Win64."
-Ronald-
"Marius Storm-Olsen" <mar
...@storm-olsen.com> wrote in message
...
> When compiling our library Qt, we get the following linker error message:
> LINK : fatal error LNK1210: exceeded internal ILK size limit; relink with
> /INCREMENTAL:NO
> This message is clearly caused by the ILK file hitting a 64MB boundry.
When
> reading
> http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs97/readme.asp we
> can clearly see that this has been an issue before as well, as the
internal
> limit on this file has been raised before.
> The internal limit makes it impossible for us to compile our library
> incrementally. This is extremly bad, since fully linking the library every
> time is _very_ timeconsuming (6-10min). Frankly, impossing such a low
upper
> filesize limit baffels me! The larger a project is, the more important it
> becomes that the linker can handle the linking process incrementally.
> Smaller projects will not benefit that much from an incremental link, as
> apposed to huge projects. So, the whole incremental linking process should
> be optimized for larger projects...
> Poor Workaround:
> Currently we are using the .NET environment to develop, and have replaced
> the bintools (bin, lib and include) with the bintools from VC 6.0 SP1, as
> that linker seems to handle much larger ILK files. The ILK file generated
by
> this old linker is about 68MB, and works just fine.
> However, this workaround is not desirable, as it introduces several errors
> between the bintools and the IDE. For one, when using the old bintools,
> breakpointing in code that resides in files with the equivalent name, but
in
> different projects, does not work. "Random" files named the same is pulled
> up and shown a breakpoint.
> So, the questions are:
> Why is there a limit on the ILK file? Will the ILK limit be increased in
the
> next SP release for the VS.NET? Is it possible to "remove" this limit,
only
> to have the OS limit the filesize? Can we increase this limit by perhaps
> binary patching the linker in VS.NET?
> And most important, is there an easy fix to this problem?
> ---
> Marius Storm-Olsen
