Borland C++ Builder Limits Debug Info to = 32Megs?

Nir Arbel asks: "After two years of using Visual C++, I've decided to try Borland's C++ Builder 5 for a small pet project of mine, to see if I wanted to make the switch. After putting BC5 through it's paces, I was ready to switch camp. Eventually though, as my project got big enough, it seemed BCB5 could no longer link my project. Searching for info, I ran into several descriptions of this exact same problem with the ultimate conclusion that the linker couldn't handle more than 32 megs of debug information. I'm reluctant to believe that this development environment is useless for large projects. Does anyone know about this problem and possible solutions to it?"

recommendation

[timmyd]

i recommend that you try posting this question on borlands newsgroups. many people are there and even people that work for borland and helpers called TeamB. i think it is either news://news.borland.com or news://forums.inprise.com. if you don't have a newsreader, you can get pan from superpimp.org or use gnus from emacs.

Re:recommendation

[Kip]

It's actually forums.borland.com

Just went there with a newsreader myself. 180 newsgroups.

Try a more reent compiler

[OmegaDan]

Try C++ Builder ... its much more recent then BC 5 which has been out in various forms since 1996 or 1997

Re:Try a more reent compiler

[DarkEdgeX]

He said he was using BCB5, which is "Borland C++Builder 5". You're confusing BC5 with BCB5. =) It's a common mistake, but he is definately using the latest version.

As for suggestions, try visiting community.borland.com [slashdot.org] and checking out their TI (tech info) and FAQ sections for Borland C++ Builder. This may lead you in the right direction for finding a solution...

My personal belief is that it's just a setting issue or perhaps some of your sourcefiles are getting too large. Also keep in mind that there's "Turbo Debugger" debugging information, and then there's the C++Builder's debugging information-- C++Builder's IDE doesn't need the Turbo Debugger debugging info to step through code or set watches on variables. Disable that if you've had it on. =)

32M of Debug not a serious limit

[bevan.arps]

I've worked for years with Borland Delphi - this now shares the same back end and debugger with C++ Builder (I've even heard that the Delphi debugger can show you the C++ code if you step into some C++ Builder code.)

My suggestion is for you to concentrate on including the Debug information you actually need in the executable - rather than all of it.

Sure, include complete information for your core application logic - but do you need all the debug info for your common libraries?

The company I work for has developed several large (man-decades of effort, dozens of executables) applications for our key client and we have a large (> 500 KLoc) library of reusable code - everything from code libraries and GUI components to Business logic and OO database persistence.

Our experience is that our fundamental libraries are soon well exercised enough that we can be confident there are few, if any, serious bugs. We therefore limit our debugging to the aspects which are unique for each application.

Alternatively, you may also want to investigate the use of runtime packages - by dividing your project into muliple links you may gain considerable flexibility, both for debugging and deployment.

Hope this helps.