32

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.

Z80
  • 19,117
  • 19
  • 138
  • 260
Max Kielland
  • 5,259
  • 7
  • 49
  • 86
  • 1
    This has been reported to QualityCentral several times over the years: [#102099](http://qc.embarcadero.com/wc/qcmain.aspx?d=102099), [#106085](http://qc.embarcadero.com/wc/qcmain.aspx?d=106085), and [#109265](http://qc.embarcadero.com/wc/qcmain.aspx?d=109265) – Remy Lebeau Mar 08 '15 at 19:54
  • 1
    All three reports are closed without any solution or workaround. I doubt this problem is project related. One guy had even reinstalled Builder and still had the problem. It must be some cached files being corrupted. I'm cleaning up all my temp folders to see if it helps. – Max Kielland Mar 08 '15 at 21:45
  • 1
    I cleaned the disk from all temporary files, emptied the trashbin and now it works again. – Max Kielland Mar 08 '15 at 22:14
  • 1
    QC often closes valid issues as "cannot reproduce" ... means that a lot of transient problems go unfixed. I had such a problem trying to use the 64-bit debugger. – M.M Mar 08 '15 at 22:40
  • 1
    @MaxKielland a similar fix is suggested in the last comment to [QC 102099](http://qc.embarcadero.com/wc/qcmain.aspx?d=102099). Would be nice if this was enough of a clue for QC to try and fix the problem – M.M Mar 08 '15 at 22:40
  • 2
    This bug in builder makes me seethe. I have had a huge exchange with Embarcadero support trying to get to the bottom of it. All my problems started with XE7 on Windows 10, along the way several things fixed it for me for a short time. Installing XE8, fixed XE7. Cleaning up my project by removing non-version controlled files. However, the one thing that has given me the biggest fix (fine for a few months until today), was making a new user account on my PC. Now I am sitting here raging at the time I'm wasting, I will never ever use Builder again by choice because of this bug. – Phil Williams Oct 13 '15 at 09:26
  • I fixed it this time by removing a `#pragma link "TMyCustomComponent"` from a form that doesn't use that control anymore. Other forms use that control and they work fine. – Phil Williams Oct 13 '15 at 10:04
  • I see that this is claimed to be fixed in 10.1 Berlin Update 1, according to: http://edn.embarcadero.com/article/44675 . However, the Resolution at the top of the RSP page for 44675 is still "Unresolved" and the "fixed versions" is "None". I'm not planning to upgrade just yet, because my workaround (use my LARGEADDRESSAWARE patched versions of ilink32; see below) works for me. But it would be nice to hear from some "stuck" user that this problem is *really* resolved. – circlepi314 Sep 22 '16 at 21:11
  • I confirm the bug is this there, in C++ Builder Tokyo 10.2. – Z80 Jan 09 '20 at 11:34

16 Answers16

23

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.

circlepi314
  • 781
  • 7
  • 13
  • 2
    In your case were you actually running into large file problems? Some of the other people having LME288 only had small projects and the error did seem to be caused by corrupted or badly-permissioned temporary file; so perhaps the same error code is used for two quite separate problems. – M.M Jun 09 '16 at 22:35
  • 50,000 lines of code in 40 modules, so, medium-sized. The problem could occur in a pristine build directory with no temporary files. – circlepi314 Jun 11 '16 at 00:41
  • 2
    I just want to let you know that your public service has not gone unappreciated - you've saved a bunch of us from this nightmare, thank you! – syco_link Nov 21 '16 at 09:31
  • Confirmed that the lamarker.exe fix worked on the XE3 version of ilink32.exe. Granted, the original was so locked down (kept getting Access Denied errors) that I had to mess around with security settings of ilink32, copy it out to my desktop folder, convert and copy back into the program directory. But after the tool ran successfully, linking no longer faulted. – depwl9992 Aug 08 '18 at 17:48
  • "With the Tokyo 2017 Embarcadero has upgraded the linker" - Nope. They fixed nothing. I still see the error in a project that has less than 700 lines of code! – Z80 Jan 09 '20 at 11:35
13

I have been having this problem as well with RAD Studio XE8 installed on Windows 10. When installed on Windows 7 (x86), RAD Studio XE8 worked properly.

After upgrading to Windows 10 (x86) I ran into the dreaded unknown heap LME288 errors. At first it didn't appear on Windows 10 but if I installed something, it would pop up. If I restored the computer to Windows 7, it would disappear.

After a little research on the net, I found the solution. There is a memory problem with ilink32.exe and you need to enable the 3GB memory space at bootup on the computer. Here is what I do now if this error is ever displayed again:

  1. Run command prompt as Administrator.
  2. Type (without quotes) "bcdedit /set IncreaseUserVa 3072"
  3. Reboot computer.

After doing that, ilink32 works properly.

I found that after installing a newer version of Acronis True Image (2016), the LME288 error came back. But running the bcdedit solution here, it fixed the RAD Studio XE8 linker!!!

Drewski
  • 131
  • 1
  • 2
4

I found a workaround that seems to work.

It seems to have something to do with corrupted temporary files. I managed to get it to work again after I did a "Disk Cleanup" on my system disk.

I Deleted all files in the list (all checkboxes checked) and also the "Clean up system files"

After that I could compile and link, even without rebooting. Even the incremental link began to work again!

Max Kielland
  • 5,259
  • 7
  • 49
  • 86
  • 3
    Thanks for sharing! This also worked for me with C++ Builder XE6. For anyone else with this issue, "Disk Cleanup" is the Windows tool (cleanmgr.exe) and not a feature of C++ Builder. – R. Schreurs Jun 08 '15 at 11:15
  • I wonder if it could be related to temporary files being owned by Administrator, and you are running C++B as user, and so it cannot write the required temporary files – M.M Aug 01 '15 at 04:52
  • Sometimes it helps, sometimes not. I wish I could withdraw my upvote. – truthseeker Oct 08 '15 at 07:16
  • 1
    I've tried this before and it appeared to work, but today I spent 3 hours trying everything that I could think of with no luck. I lost the count on how many times I run the Disk Clenaup, restarted, cleaned by hand all temps, ran as Administrator, and so on. What appears to did the trick was to change the amount of virtual memory. I had it to "Size managed by the OS" but I set it manually somewhat bigger and now it works... lets see for how long :( – Rodrigo Gómez Oct 15 '15 at 18:20
  • I had to reboot after running Disk Cleanup and that fixed it. – Jim McKeeth Jan 20 '16 at 20:45
  • I don't see why deleting the temp folder would fix this issue. – Z80 Jan 09 '20 at 09:44
  • @Antikythera No one is telling you to delete the tmp folder, but cleanup the disk will remove the temp files. I suspect that the problem may be cause by a corrupt tempfile used by the linker. However, now with Rio 10.3.3 they claim the problem has been solved, but I found it to be disguised as LME error 200 instead. – Max Kielland Jan 25 '20 at 19:55
  • @MaxKielland - I don't understand your logic. If the malfunction is (as you state) in the temp folder, deleting the temp folder should fix it. Why bother running the Disk Cleanup utility? – Z80 Jan 26 '20 at 12:38
  • Your answer is plain Voodoo. C++ builder does not put the compiled files in the temp folder. It uses the folders specified in Project Options for output. It does create an empty file called tmp46139df.tgs. If that file gets corrupted (I don't know how you can corrupt the information in a zero-byte file), then deleting the temp folder is enough. So, why do voodoo and run the Disk Cleanup? – Z80 Feb 06 '20 at 10:16
  • Even more, even if it would output something in Temp, all temp files should be overwritten on Build or on IDE restart! – Z80 Feb 06 '20 at 10:16
  • 1
    @Migrate2Lazarus This whole error is Voodo and people are trying a lot of things out of desperation. This works for some and not for others. The temp directory isn't the only places where there might be temporary files and there is no law saying that they are overwritten, it's up to each application. – Max Kielland Mar 31 '20 at 18:59
  • "This whole error is Voodo and people are trying a lot of things out of desperation" that is something I 100% agree upon. This is why I try to convince people to migrate from Delphi to Lazarus. We have the source code there. We can fix bugs by ourselves. AND we don't have to pay thousands of $ to embarcadero for buggy products anymore. – Z80 Apr 01 '20 at 11:02
  • @Migrate2Lazarus You might have missed that this isn't about Delphi, its about C++ and seems to have something to do with the 32bit linker; ilink32.exe. – Max Kielland Apr 01 '20 at 19:19
  • 1
    @MaxKielland - nope. it is not about C++ Builder or Delphi, it is about the daily bug we encounter in Embarcadero commercial products, bugs that we got used to shut up about them. Bugs that haven't been fixed for YEARS even if they crash the IDE/compiler hourly. – Z80 Apr 02 '20 at 09:41
  • @Migrate2Lazarus I'm ending this 'chat' now. If you have some helpful information for the problem, related to C++ Builder (not any Delphi related), please feel free to write an answer. – Max Kielland Apr 02 '20 at 21:54
4

Just running XE8 as administrator fixed it for me.

AashishPatel
  • 51
  • 5
4

As Drewski I ran into the LME288 error after the upgrade to Windows 10 (x64).

The error disappeared changing the Data Execution Prevention settings for ilink32.exe:

  • System properties -> Advanced system settings -> Performance -> Settings -> Data Execution Prevention
  • Turn on DEP for all programs and services except those I select -> ilink32.exe.
Community
  • 1
  • 1
manlio
  • 16,658
  • 13
  • 67
  • 107
2

In my case, trying all the other options here mentioned didn't work at all.

What seems to did the trick was setting manually the amount of virtual memory, in the System Settings of my Windows 10 machine. It was set to be managed automatically by the Operating System, but changing it to a manual value (even when the minimum was less than what was assigned automatically, and it is what is being used actually) made the linker work again.

In my case the OS had assigned something like 1,600 Mb. I set the minimum to 1,024 and the maximum to 3,072, restarted, and now the linker is working fine. The amount used says 1,024 (even when the recommended value says ~1,900).

Rodrigo Gómez
  • 1,059
  • 7
  • 22
1

I have a different solution that hopefully will help someone struggling with this.

I tried everything and none of the solutions suggested earlier worked for me. Disk cleanup didn't help. This is clearly a bug in C++Builder that existed for many years, and is still not fixed even in XE8 as of 2015.

Luckily, I had another computer with working environment, where the same project did compile. I copied all files (*.exe, *.obj, etc) from the output directory (Win32/Debug) from that computer to the one where I had the problem, and that magically set C++ Builder straight; all builds afterward started to work.

Cozzamara
  • 1,268
  • 1
  • 13
  • 21
1

Fixed for XE10 and Windows 10 (x64) with Bitdefender IS 2016:

Bitdefender -> Modules -> Antivirus -> Exclusions -> Excluded Processes -> Add "...\bin\ilink32.exe" -> Allow

ravdouha
  • 31
  • 3
1

Rebooting W10 solved this issue on XE5 but I am desactivating incremental build

Lotfi
  • 508
  • 1
  • 4
  • 18
0

We has the same issue and solved it by increasing the virtual memory for Windows (it was very low, 800Mo, it is now about 4 Go)

Tunaki
  • 116,530
  • 39
  • 281
  • 370
RickInfoDEV
  • 3
  • 3
0

I fixed this by ensuring that the Embarcadero installation folder (e.g. C:\Program Files (x86)\Embarcadero) was excluded from all antivirus scans.

RobinP
  • 71
  • 3
0

The solution is very simple: the windows PATH environment variable exceeds its limit of 2047 bytes.

Please see my description here: http://blog.bitart.at/lme288/ [German]

Edit: My "solution" only lasted for a couple of months. After installing Microsoft Visual Studio the problems returned.

As mentioned in another answer: Patching ilink32.exe with

lamarker -M -Filink32.exe

seems to be the correct solution.

Herwig
  • 177
  • 13
0

Windows 10(x64), Rad Studio XE Berlin (incremental link enabled).

I fixed the problem by excluding "C:\Program Files (x86)\Embarcadero\bin" from antivirus Window Defender scans.

Andrey Kouvaev
  • 1
  • 1
0

Changing the IDE language from french to english with BDSSetLang.exe solved for me the LME288 error !

Lotfi
  • 508
  • 1
  • 4
  • 18
0

It seems that with the linker supplied with 10.2.3, TDS heap size can be set up to 0x1FF00000. In the older and newer versions, this maximum is smaller (gives LME200). If you need a large heap size, I recommend using the linker from 10.2.3. I have also opened a bug report about this: RSP-27205

vll
  • 7,507
  • 1
  • 23
  • 42
0

Seems to be absolutely random to me... I also got the "unknown heap name" failure. I tried a lot of the solutions abovve, none of them worked. I tried the ilink from circlepi314, tried to clean the temporary files, multiple reboots, etc. On the linker failures page from Embarcadero I found that the calling convention from dlls might cause trouble. My project did contain calls to a dll. I excluded these calls, compiled and it linked again without any issue. Right after that I included these calls again and it also linked without any problems any more. Although I even cleaned the project in between. I even cannot reproduce it anymore. There must be somewhere some residues which are used by the linker and which are gone now. So hopefully this might help somebody in future.

Bodo
  • 3
  • 2