LNK1248 error on solution that works with VS2010 & VS2012

[Price__Jeff]

I'm trying out the Intel compiler on a Windows solution that we've been building for some time with VS2010 tools (through VS2012). I have made no changes to the default settings, just set the solution to use the Intel compiler. On build, I'm getting the subject line Iink failure "LNK1248: image size (80000016) exceeds maximum allowable size (80000000)." I've read the Memory Limits for Applications on Windows article, but don't believe that exactly applies since I know I can build and run our production code with VS2010/12. Any ideas on how to solve this problem would be appreciated.

[TimP]

A discussion on software.intel.com a little over 2 years ago found that moving static data to dynamic heap could overcome this.  No doubt you saw the standard Microsoft recommendation about splitting your application into more .dlls.

[Price__Jeff]

The MS toolchain works for us, though, and has for several years. The exact same source code, using the default MS compile/optimize settings for release, compiles and runs just fine using the MS compiler, yet fails with the Intel compiler. Is there some setting whose default differs between the MS and Intel compilers?

[JenniferJ]

I'm trying to see if I could duplicate the issue, but no. not with 14.0 or 15.0 beta.

is it win32 config or x64? make sure to add "/LARGEADDRESSAWARE" to the linker. can you send a testcase? or it only happens with your big app?

Thanks,

Jennifer

[Marián__VooDooMan__M]

I had the same error message when I have turned off precompiled headers. You may try to use precompiled headers.

[Marián__VooDooMan__M]

Marián "VooDooMan" Meravý wrote:

I had the same error message when I have turned off precompiled headers. You may try to use precompiled headers.

Though, I have no idea why this is working, but IMO when precompiled headers are disabled, compiler is duplicating code for each object file. When precompiled headers are enabled, compiler doesn't need to duplicate code that is already compiled, thus it doesn't exceed the limit.

[Price__Jeff]

The issue is indeed code size. For our largest module, the VS2010 toolset (being run through VS2012) produces a *.lib that is approximately 340MB in size while the Intel generated *.lib was exceeding 2GB. I brought it under the 2GB limit by breaking apart that library into two separate libraries. Are there any settings that could be suggested to reduce the size of the code that, ideally, would not have a significant impact upon the performance improvements we are hoping to realize?

[David_W_6]

I'm having the same error on a large library that compiles fine on VS2008 through VS2015. Our release build using VS is about 1GB in size. It's over the 2GB limit with the intel compiler with ALL the optimizations turned off. I've been trying to split it up but this isn't working. I believe the culprits to the bloat are several template classes that are expanded during compilation. Thus, even if we split it into different parts, if any of those parts use the templates it fails. We're not able to separate the templates from one another within the library.

The more frustrating thing is that the size the linker is reporting is only about 20MB over the 2GB limit. Make no sense for a .lib to have a 2GB limit...when we finally build our exes that use the lib they shrink down to 20MB or so in size.

[TimP]

Icl offers /Os to compile for minimum code size at expense of performance or /O1 to balance size and performance. Multiple code path options like /QaxAVX consume much space.