Well, I finally took the plunge and Embarcadero's advice to solve my C Builder 2007 linker woes by moving my application to C Builder XE.
I am UNHAPPY to report that after 3 weeks of conversion, I still get the same ERROR:
[ilink32 Error] Fatal: Out of memory
I would REALLY APPRECIATE an answer from someone at Embarcadero on how to solve this problem.
Best Regards,

David I of has responded with a couple of ideas that helped me out (mainly using debugging info on only selected modules at one time). I wasn't aware that C Builder's project manager allowed this since it was removed in Borland C++ 5.0 over 15 years ago !
  Hope this helps someone else with this problem!
  Best regards,
  Shane
  

(snip)

Hi Shane,
    thanks for sharing this information. I'm having the same problem for a while with RAD Studio 2007 and 2010. I tried several solutions like unilinker (it links my project, but it crashes even before I get in the main thread), building my exe with runtime packages,... the only thing that really works is disabling the incremental linker. But without the incremental linker, even if you change a single line of code, a full link of more than 3 minutes is done. :(
    I tried your solution and it seems to work (for now, because it always works for a few days and then it chokes...) although it is a drag to having to change the compiler / linker options unit per unit...
    To bad to hear that even in Builder XE, the same problem persists. Does anyone know if Embarcadero is planning to deliver an improved linker with the next RAD Studio? Or will it be for RAD Studio 2020?
    Could you tell me the other ideas that helped you out besides using debugging info only for a few selected units?

Steven,
  It got to same point with the XE linker. My current work around so that I can still use incremental linker is to basically do the same mentioned strategy but a little more "brute" force.
  What I do now is:
  1) Edit the Release options and set the Output director to Debug.
  2) Do a full release build.

On Wed, 16 Feb 2011 06:45:55 -0800, Shane Stump <> wrote:
    (snip)
"blessed are those who believe"
    --
    Vladimir Ulchenko aka vavan
    

(snip)

Hi Shane,
    thanks for the information. It is indeed a 'crappy' workaround :) with lots of disadvantages, but everything is better than not being able to link. Can you keep me informed if you have news from David I? Will they provide a new linker in an update or will it come with the next release of Rad Studio?
    Thanks Steven.
    
    

(snip)

I might be INSANE for believing them as I have only been crying about this problem for 5+ years but I think a 64 bit linker will finally raise the limits!
  Only time will tell.
  Best Regards,
  Shane
  

Steve,
  I will let you know when I get a better solution / answer.
  Best Regards,
  Shane
  

Hi Shane,
    thanks! Looking forward to hearing the good news from you!
    
    
    

(snip)

Are there any updates/improvements to this situation? I'm running into a similar memory problem with the ilinker on large projects. Between your communications with David, were you guys at least able to isolate the root cause of this?
    Thanks
    
    
    

(snip)

VicT,
  I didn't see your post!
  I got the linker working for a while but I am back to being DEAD IN THE WATER.... The linker either runs out of memory or if my program does link, it blows up with an EACCESSERROR in the initialization code.
  I am not sure what to do as my non-technical partner thinks I can just recompile or rewrite our large program in a Microsoft language!
  Best Regards,

wrote in message news:✉forums.embarcadero.com...
    (snip)

Some thoughts...
    If the program (resulting executable) is that large...
    1)Do you have graphic images statically loaded into VCL form objects
    (TPictures, TBitmaps, TImage, or others?), that could be removed and loaded

David,
  Thanks for posting!
  1) The executable is quite large (120MB) as it contains all my modules + DevExpress + TMS + NexusDB + several others! I have used this approach over the years of this product because of how our program is used / distributed by our customers (as it currently stands, it only takes the EXE + one encrypted INI file).
  2) Moving to BPLs / DLLs is something I refuse to do because of to many DLL hell experiences in the past.
  At this point, I need to give up that I am ever going to get an ILINK32 that actually can use 4GB of memory! I have been on the phone with customers all morning going over the various approaches and I (we) have decided that I am going to break our application into stand-alone modules (EXEs) and I am going to create a program launcher to navigate / control them!

We had some success with unilink (ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0311.zip).
    1. Backup both ilink32.[exe|cfg] from bin folder.
    2. Rename ulink.exe into ilink32.exe
    3. Create new ilink32.cfg with (add/adjust paths as required)
    {code}

Lewis,
  I have never gotten ulink to work with my program! My program is very, very large (120mb when it links properly).
  The reason I statically link it is because several of our users like to put it on the a usb thumb drive and take it to remote sites (and with just two required files, it has worked out well).
  I am going to take a few hours now to start my project over from scratch and see if my project file just got messed up.
  If that fails, I will try the latest version of ULINK again since my alternatives are not what my partner/investors or customers want to hear!

Hello,
    I'd seriously reconsider building with dynamic RTL & packages. If you
    need single-file deployment, you could wrap your executable in a
    self-extracting archive which extracts all the required DLLs along with
    your executable. This should also cut your build times a lot.

(snip)

Moritz,
  I am definitely not going back to DLL (or BPL) HELL !!
  As far as build times, I use TWINECOMPILE + I have an INTEL 980X CPU, 24GB of memory, and two 512GB SSDs. Development speed hasn't been an issue for me for a while... just getting the linker to work consistently has!
  If my current endeavor fails, I will be writing a program launcher and breaking my program up into separate EXEs until I can finish my C++ plug-in framework I have been working on.
  Have a GREAT weekend,

Hello,
    Shane Stump wrote:
    (snip)
okay.
    (snip)
Yes, the linker can be a PITA.
    I don't know how well this works, but you could try to give ILINK a bit

(snip)

I will give that a try to!
  I am adding each of my 400+ units on at a time to my project and making sure my project status doesn't get corrupted.
  The sad thing is, I have been extremely happy the last several months using C Builder XE when I can get the linker to work. C Builder XE has been the most stable version of the C Builder series for me!
  Best regards,
  Shane

Hello,
    Shane Stump wrote:
    (snip)

the JVCL Packages Generator can be a great help in keeping multiple
    project files in sync, regenerating messed up project files etc. And it
    isn't limited to packages. I currently use it for package projects

(snip)

Thanks for the recommendation - I will have to check it out!
  (snip)
Best Regards,
  Shane
  
  

Well, I finally got the linker working again by
    1) Rebuilding my project completely (3rd time this week)!
    2) While compiling in debug mode, disabling Full Debug Info and only including line info.
    When I include Full Debug Information, the linker bombs out with an Out of Memory error when the linkers' memory usage hits around 285MB!
    Since I am using the latest linker they are using, I am guessing I will never get a usable fix until maybe the 64 bit linker comes out!

(snip)
Hi,
  We have been facing this issue form long, and were able to find different work around but as the project size if growing we are finally trapped, but I hope these solutions might work for few of the guys.
  But I can guarantee as, this out of memory error is not consistent.
  Solution 1: Before you build the last project, the one which links all the depending libraries, search in all project group for files *.#* If you get files with these names delete them and then try to compile and link the last project that gives you the exe. It worked for me for around 2 years. If you are interested in debugging a specific library, can try not deleting these files from that particular library.
  Solution 2: As already suggested earlier, can build few of the projects in release more and few in debug, for us all those project (libs) that were pure c++ (no vcl) we did it in release and other in debug, and that worked. BUT if you use this and try your exe on win7 64/32 bit exe fails to run even though it will run successfully on win xp 32 (this is the only OS I could test). Thus solution 2 is valid till you are not moving to win7.

wrote in message news:✉forums.embarcadero.com...
    (snip)

FWIW...
    Don't know what your error is... BUT, I have a project, that with trials of
    both 2009 and XE, would fail within the IDE, but, if I extracted the command
    line and executed it from a command prompt outside of the IDE, the same

In article <✉forums.embarcadero.com>, jitendar rawat <> wrote:
    (snip)
If you get files with these names, You've got a problem with your
    precompiled headers.
    --
    -David

(snip)

Edited by: jitendar rawat on Jun 14, 2011 9:00 AM
  
  
  
  

(snip)

Any pointers what it could be. Or is there a way I can get warnings about it form compiler.
  
  
  
  

In article <✉forums.embarcadero.com>, jitendar rawat <> wrote:
    (snip)

It means that different cpp files in your project are including
    headers in a different order. every .cpp file in your project should
    start with the same exact lines before the #pragma hdrstop line.
    --

(snip)

Thanks David,
  I took the smallest project and did ceck what you have suggested above. All my files had an entry of just the precompied header before #pragma hdrstop. But still I can see that compiler is making a bcb2006_debug.#00 in the precompied headers folder.
  Also I am now using ulink.exe rather than ilink32.exe and I am no longer facing the out of memory issue for the same project wher ilink32 fails. But having said that, I tested it with TChart in my project, but it failed with undefiend vtable error which definitely looks to be related to ulink.
  Jeet
  

In article <✉forums.embarcadero.com>, jitendar rawat <> wrote:
    (snip)

#00 is ok. it's when there is more than one that it's a problem.
    --
    -David
    

Jeet,
    I have been through all your exercises and I feel y'alls PAIN!!!
    I sure wish Embarcadero would fix the the reported bugs / short comings to C Builder before moving onto new features.
    Best regards,
    Shane

This Linker-Bug exists since more than 10 years. Nothing happened yet.
  The only solution is to split your projekt in DLLs/BPLs.
  Best regards
  Michel
  (snip)

Edited by: Michael Messner on Jul 21, 2011 4:46 PM

Michael,
    I know the problem has always been skipped over by the C Builder team (heck, I have been reporting the problem for what seems like 10 years)!
    Breaking my program into DLLs/BPLs isn't going to happen unless that becomes a LAST resort because of how our program gets used (updating just one file that doesn't require any special rights makes it easier for our customers who have "remote" sites).
    I have finally gotten the XE linker to work by only having debug information in one module at a time.
    At this point, I am thinking the ONLY fix will be when the product goes to 64 bit later this year (I am of course assuming the linker will also be 64 bit)!

wrote in message news:✉forums.embarcadero.com...
  (snip)

Of course, I don't know that they've stated the product itself will be
  64-bit - merely that it will target 64-bit platforms. The actual tools
  could still be 32-bit... And 32-bit tools would run on either platform, so
  that they didn't have to maintain both.

Shane,
  We fighted this problem for years and we are now very happy that we splitted the project (about 1.5 Mio lines of code).
  Debugging was a pain. Allways the parts of code you needed had no debug-info. Now we can debug the complete project. Only for that reason it is worth to split the project.
  Best regards
  Michel

Michael,
    I don't disagree with your assessment, but the only way I would break my program down at this point would be a plug-in system (I actually started writing one two summers ago)! The problem I have now is that I have a "to-do" list that is LONGER (and getting LONGER) and I just don't have the time now to re-engineer my program. If it gets to the point the linker just completely breaks, I will obviously have no choice.
    I keep hoping that Embarcadero will at least bring the linker into the early 2000s since the old one seems to have limits from the mid-1990s !
    Best Regards,
    Shane

Has anyone found out whether the C++ XE2 compiler and linker have been rewritten to be 64-bit on supporting platforms? This may well alleviate such memory bottlenecks. Shane, are there settings that allow to you to specify heap and stack linker memory constraints (command line options) as there were in BCB5?
  --
  Mark Jacobs
  www.dkcomputing.co.uk
  

(snip)

Mark,
    I am hopeful that the C++XE2 will fix the problem via 64 bit! But I will believe it when I see it; with my luck, the 64 bit linker will be a 32 bit application with about the same limits.
    I will have to check on the linker command line options when I am in my office. I am answering this on my tablet!
    Have a good day!
    Shane

Hello,
  Shane Stump wrote:
  (snip)

C++Builder XE2 will probably not support Win64; this is scheduled for
  XE3 according to the roadmap. XE2 will bring Mac support though.
  --

Mark Jacobs <> wrote:
    (snip)

XE2 has been released. It does not include a 64 bit C++ compiler. You
    should be able to download the trial version to test the linker for
    any improvements. About all I can say so far is that the compiler
    version is different - not sure how many bugs may have been fixed.

HAPPY NEW YEAR ALL!!!
  << I removed message as the Out of Memory issue is still there with the latest XE 2 linker>>!!
  Shane
  Edited by: Shane Stump on Jan 1, 2012 1:24 PM
  

Hello,
    I´m having the same problems with all Borland/Codegear/Embarcadero linker versions (from CG2007 to XE2). Unfortunately the developer team seems to be eager for new and fancy features instead of adressing core issues.
    I´m currently trying to get UniLinker V1.07 beta build 331 working, but I don´t quite succeed. I´m using Andreas Hausladen´s bcc32pch plugin to specify an external linker (ulink.exe) with the following ulink.cfg:
    {code}
    -L

caveat: I have not tried to use unilink in any fashion, but a thought...
   wrote in message news:✉forums.embarcadero.com...
  (snip)

Do you have a directory 'Obj' specified in your project options/paths
  somewhere, that either doesn't exist, or, isn't found by unilink, perhaps
  due to different "relative" working path locations...?

Hi,
  Not sure if it'll help, but here I've renamed ulink.exe (v1.07b3.31)
  into ilink32.exe, and so, on ilink32.cfg I'm using (for CB2010) the
  following:
  {code}

On Tue, 28 Feb 2012 08:34:19 -0800, david hoke <✉east-shore.com> wrote:
    (snip)

in bds2006 there's no need to such rush :)
    bcb (up to bcb2006 that is) can generate make file
    then one can simply use make -K to keep response file
    what a shame they decided to transit from using make to msbuild in later versions :(

Thanks for your suggestions, I´m a bit busy at the moment so I cannot investigate further.
  I´ll return as soon as possible.
  
  
  

28.02.2012 17:35 tarihinde, Guido Niewerth yazdı:
  (snip)

Guido,
  Did you contact with unilink guys showing your problem
  I'm using BCB6, and I had a similar problem with using unilink, it was
  complaining that it couldn't find a directory within a file. I've

On Sat, 19 May 2012 22:07:16 -0700, sabetay toros <✉bilsarsoft.com> wrote:
    (snip)

    unilink is single developer product
    
    on everything else I totally agree

Thanks for your suggestion,
    I was unable to fix the issues with unilink, so I did not try any further. Since I am not the only one having problems with Embarcadero RAD Studio our team decided to switch to MS Visual Studio in the long term, which will terminally fix any linker errors ;)
    Thanks for your suggestions, anyway.
    
    

Guido Niewerth wrote:
  (snip)

BTW, release notes on new ulink versions often mention MS issues.
  No perfection in this world.
  :-)
  --

21.05.2012 09:05 tarihinde, Vladimir Ulchenko yazdı:
  (snip)
Vladimir,
  I wasn't aware of it. Do you know the name of the developer.
  Thanks
  Sabetay

Yury Haron if I'm not mistaken.
    
    
    
    

On Tue, 22 May 2012 06:31:01 -0700, Luis Branca <> wrote:
  (snip)
or Iouri Kharon (actually that's how his name is spelled in his foreign passport as I was told)
  --
  Vladimir Ulchenko aka vavan
  

(snip)

I am running into the same problem, but I think I found a workaround that works well and that does not imply using DLLs nor BPLs: I compile some of the project's modules in a separate static library (.lib). This has worked so far very well for me.
  There is very little extra work to do: all you need is define and create the library project. Once this is done, you get: full debug support for all functions inside the library, automatic check of the library before building the exe (set from Project | Dependencies...), and you still have a single exe to distribute. IOW, you can go on concentrating on your development instead of the limitations of the linker.
  Best regards,
  Henri.
  Edited by: Henri Picot on Oct 15, 2012 9:32 AM