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
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
news:#aDhhbPICHA.2680@tkmsftngp12...