linker errors - How to fix "LME288/Unknown heap name" warning?

Question

Suddenly, out of the blue, I get the LME288 linker error.

[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ilc: 0x00010000 / 0x08000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ild: 0x00010000 / 0x08000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ilf: 0x00010000 / 0x0a000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ils: 0x0003b000 / 0x08000000
[ilink32 Warning] Warning: unknown heap name   : 0x08000000 / 0x08000000
[ilink32 Warning] Warning: Error detected (LME288)
[ilink32 Error] Error: Unable to perform link

I have no AV installed and the project has been running fine for over a year. I have tried:

• Incremental linker disabled/enabled, no difference...
• Manually removing all files in /debug, still no change...
• Full Build, no difference...
• Reboot computer, no changes...

This has been asked before here but no real explanation or solution was presented.

What else can I do to fix this?

EDIT
I tried to rebuild a couple of other projects that has been running fine for years and now I get the LME288 error on all my projects.

Answer 1

On 15 Jan, 2020, Embarcadero changed the status of RSP-12869 from "Needs feedback" to "Open" and assigned it to Internal Dev.

Older History: With the 10.2 Tokyo release of C++ Builder in April 2017, Embarcadero upgraded the linker, claiming to solve the problem: "The linker is now large address aware and can address up to 4GB on a 64-bit system, twice the previous amount. (Some customers hacked the linker to be LAE [sic] in the past by toggling the bit in the PE header; since the code wasn't written to be LAE-aware this hack prevented incremental linking and sometimes other functionality from functioning correctly.)" https://community.embarcadero.com/blogs/entry/what-s-new-in-c-builder-10-2-part-1-the-linker

However, on May 24, 2017, Ashleigh Quick reported that 10.2 Tokyo's linker still does not resolve the problem: RSP-12869. Similarly, @Ultralisk reports the same problem in a comment below on 2020-01-09.

Here's one workaround: beginning with 10.2 Tokyo, you have some new options to control LARGEADDRESSAWARE and linker heap sizes. Dieter Woellner reported on 26-Oct-2017 that, temporarily, setting C++-Linker | Advanced | Advanced Options entry to "-GF:LARGEADDRESSAWARE" eliminated the problem. But the problem returned, and he discovered that if you set the TDS Heapsize to a value below 0x08000000 you avoid the error/crash on linking...for now.

=====================================

I am one of those customers who hacked the linker to be LAA, thereby interfering with incremental linking (which I don't need) and solving my problem. If you don't need incremental linking, read on.

=====================================

I resolved the problem by setting the /LARGEADDRESSAWARE flag in ilink32.exe. The original solution came from Hiroyuki Shimada, using editbin, and posted at http://qc.embarcadero.com/wc/qcmain.aspx?d=134775 on 1/12/2016. He also applied it to bcc32.exe; I didn't need to.

As a public service, I have posted my patched ilink32.exe versions here:

• RAD Studio 10 Seattle: https://s3.amazonaws.com/public-mfay/ilink32.exe
• RAD Studio 10.1 Berlin: https://s3.amazonaws.com/public-mfay/ilink32-10.1.exe

To use either, rename your ilink32.exe in your RAD Studio binaries directory (e.g. C:Program Files (x86)EmbarcaderoStudio17.0in for RAD Studio Seattle, or ...18.0in for Berlin), and copy mine in its place, renaming it to ilink32.exe.

[Note: these /LAA linkers solve the problem for many, but not all users; see @Andrew Legget's post on 7/25/2016 at https://quality.embarcadero.com/browse/RSP-13247]

This problem has been around for a long time and is not limited to XE3, XE5, XE7, XE8... There is now a lengthy discussion/lament at https://quality.embarcadero.com/browse/RSP-13247 as to why this was fixed in one version of RAD Studio but backed out in a later version; apparently /LAA "resulted in failures when linking incrementally with the static RTL". According to the 28/Mar/16 12:14 PM post by Dennis Jones in that thread, the /LAA patch does NOT address the other linker errors "EXE1825" or "out of memory".

Read below if you want to see three ways in which ilink32.exe can be patched...

---

1. Set Large Address Aware flag with the lamarker tool, downloadable from: http://cc.embarcadero.com/Item/30459 (thanks to Doug Hay, 19/Jul/16 post in https://quality.embarcadero.com/browse/RSP-13247):

   lamarker -M -Filink32.exe

(You may do this directly in your C:Program Files (x86)EmbarcaderoStudio17.0in (or ...18.0in) directory; it will rename the original ilink32.exe to ilink32.exe.old -- if you have permission)

--OR--

2. Use editbin from MS Visual Studio, if you already have such installed (Microsoft claims that editbin must be run from within the IDE). As a preliminary step, copy bcc32.exe and ilink32.exe to prevent UAC's block (and to back them up)

   copy "C:Program Files (x86)EmbarcaderoRAD Studio12.0incc32.exe" .

   copy "C:Program Files (x86)EmbarcaderoRAD Studio12.0inilink32.exe" .

   editbin /LARGEADDRESSAWARE bcc32.exe

   editbin /LARGEADDRESSAWARE ilink32.exe

-- OR --

3. Set the Large Address Aware flag using editbin from the masm32 package:

Download from http://www.masm32.com/download.htm, which creates c:masm32ineditbin.exe. I got a few warnings (involving ordinals 201 and 203) during MASM32 installation but its self-test passed, and all I needed was editbin.exe.