linker-errorsc++builderwindows-7-x64c++builder-10.2-tokyoc++builder-xe7

How to fix "LME288/Unknown heap name" warning?


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:

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.


Solution

  • 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:

    To use either, rename your ilink32.exe in your RAD Studio binaries directory (e.g. C:\Program Files (x86)\Embarcadero\Studio\17.0\bin for RAD Studio Seattle, or ...\18.0\bin 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)\Embarcadero\Studio\17.0\bin (or ...\18.0\bin) directory; it will rename the original ilink32.exe to ilink32.exe.old -- if you have permission)

    --OR--

    1. 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)\Embarcadero\RAD Studio\12.0\bin\bcc32.exe" .

      copy "C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\ilink32.exe" .

      editbin /LARGEADDRESSAWARE bcc32.exe

      editbin /LARGEADDRESSAWARE ilink32.exe

    -- OR --

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

    Download from http://www.masm32.com/download.htm, which creates c:\masm32\bin\editbin.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.